Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"В systemd-journald спустя 6 лет признали проблему избыточной нагрузки на накопители"	+/–
Сообщение от opennews (??), 15-Авг-26, 00:23
Разработчики проекта systemd приступили к изучению и устранению давней архитектурной проблемы в компоненте "systemd-journald", приводящей к многократному завышению объёма записываемых на диск данных (write amplification) по сравнению с фактическим объёмом логов... Подробнее: https://www.opennet.ru/opennews/art.shtml?num=66082
Ответить | Правка | Cообщить модератору

Сообщения

[Сортировка по времени | RSS]

1. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+2 +/–
Сообщение от Аноним (1), 15-Авг-26, 00:23
Всю жизнь монтирую /var/log в tmpfs кстати.
Ответить | Правка | Наверх | Cообщить модератору

	2. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+57 +/–
	Сообщение от Аноним (2), 15-Авг-26, 00:25
	Удачи потом в расследовании инцидентов.
	Ответить | Правка | Наверх | Cообщить модератору

	15. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+8 +/–
	Сообщение от Аноним (15), 15-Авг-26, 01:04
	Можно подумать, что ты хоть раз расследовал на гигабайтах логов. Есть смысл временно включать, чтобы проверить почему падает отдельная служба, но держать на постоянке и никогда туда не смотреть... ну ты сам себе буратино.
	Ответить | Правка | Наверх | Cообщить модератору

	19. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+2 +/–
	Сообщение от Аноним (2), 15-Авг-26, 01:21
	Гигабайты там и не нужны. Хватает 100 строчек выхлопа тогоже ядра, чтобы понять, почему вся система отъехала. К слову, актуально даже на десктопе с теме же амдешными, кривыми GPU дровами.
	Ответить | Правка | Наверх | Cообщить модератору

	34. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+1 +/–
	Сообщение от Аноним (1), 15-Авг-26, 02:19
	Ничего не мешает убрать маунт при необходимости. Хотя при паниках ядра в журнал все равно ничего не запишется.
	Ответить | Правка | Наверх | Cообщить модератору

	163. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+5 +/–
	Сообщение от Аноним (163), 15-Авг-26, 15:36
	На всякий случай юзерам: # Remove journals older than a specific time sudo journalctl --vacuum-time=2d     # Keep only last 2 days sudo journalctl --vacuum-time=7d     # Keep only last 7 days sudo journalctl --vacuum-time=2weeks # Keep last 2 weeks sudo journalctl --vacuum-time=1month # Keep last month # Remove journals until total size falls below a limit sudo journalctl --vacuum-size=500M   # Keep only 500MB of logs sudo journalctl --vacuum-size=1G     # Keep only 1GB sudo journalctl --vacuum-size=100M   # Aggressive cleanup # Remove journals beyond a certain number of files sudo journalctl --vacuum-files=5     # Keep only 5 journal files # Combine: time AND size (more restrictive wins) sudo journalctl --vacuum-time=30d --vacuum-size=1G # Verify how much space was reclaimed journalctl --disk-usage Посмотреть размер папки /var/log/journal после манипуляций: du -sh /var/log/journal
	Ответить | Правка | Наверх | Cообщить модератору

	167. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+2 +/–
	Сообщение от Аноним (-), 15-Авг-26, 16:13
	>[оверквотинг удален] > sudo journalctl --vacuum-size=100M   # Aggressive cleanup > # Remove journals beyond a certain number of files > sudo journalctl --vacuum-files=5     # Keep only 5 journal > files > # Combine: time AND size (more restrictive wins) > sudo journalctl --vacuum-time=30d --vacuum-size=1G > # Verify how much space was reclaimed > journalctl --disk-usage > Посмотреть размер папки /var/log/journal после манипуляций: > du -sh /var/log/journal При том чтобы этим всем особо не заниматься можно еще сделать что-то типа: SystemMaxUse=32M ...в файле /etc/systemd/journald.conf в секции [Journal] и более вон то не потребуется. Да-да, в s-d есть встроенный "логротейт" и можно ограничить размер БД не по датам даже - а по месту которое мы согласны отдать на логи. Будет как этакий кольцевой буфер, хоть за столетие если менее 32 мегов, а при активном флуде - интервал сократится, но более 32 мегов все же не будет. Ну или сколько там кому не жалко на логи.
	Ответить | Правка | Наверх | Cообщить модератору

	228. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (228), 15-Авг-26, 22:21
	А смысл ограничивать время хранения логов systemd какими-то днями или неделями? Проблема возникает на этапе собственно записи сообщений. Их можно хоть немедленно удалять, от этого проблема избыточного объёма записываемых данных никуда не уйдёт.
	Ответить | Правка | К родителю #163 | Наверх | Cообщить модератору

	41. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (-), 15-Авг-26, 02:40
	> Гигабайты там и не нужны. Хватает 100 строчек выхлопа тогоже ядра, чтобы > понять, почему вся система отъехала. Но с tmpfs строчек будет зачастую 0. Почему-то.
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	171. "В systemd-journald спустя 6 лет признали проблему избыточной..."	–1 +/–
	Сообщение от NameName (?), 15-Авг-26, 16:37
	ты там чемто упоролся? вся досточно 100 строчек выхлопа, но нужно найти эти 100 строчек в гигобатах логов.
	Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

	174. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+1 +/–
	Сообщение от Аноним (174), 15-Авг-26, 16:48
	Умение искать переводит ситуацию из категории "проблемы" в категорию "решаемой задачи".
	Ответить | Правка | Наверх | Cообщить модератору

	175. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (175), 15-Авг-26, 16:48
	> в гигобатах логов а зачем ты пишешь гигабайты логов в секунду? это же как забивать гвозди бетономешалкой. теоретически можно, но никто так не делает.
	Ответить | Правка | К родителю #171 | Наверх | Cообщить модератору

	16. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+4 +/–
	Сообщение от Аноним (16), 15-Авг-26, 01:06
	> Удачи потом в расследовании инцидентов. Может он эти инциденты и создает? "В расследовании главное не выйти на самого себя!"
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	229. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (228), 15-Авг-26, 22:22
	> Может он эти инциденты и создает? Ну так-то да, у грамотного сисадмина железо и девушки не ломаются.
	Ответить | Правка | Наверх | Cообщить модератору

	76. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+2 +/–
	Сообщение от Аноним (76), 15-Авг-26, 07:19
	А с journald там тоже рулетка. Во время инцидентов он теряет или повреждает свои логи
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	103. "В systemd-journald спустя 6 лет признали проблему избыточной..."	–1 +/–
	Сообщение от Аноним (-), 15-Авг-26, 10:53
	> А с journald там тоже рулетка. Во время инцидентов он теряет или > повреждает свои логи 1) Там в отличие от <random program name> - sync сделан более-менее грамотно. И оно это делает - потому что например при панике семантика файловых операций все же может быть нарушена. Но редко. И, главное, детектируемо. 2) Там есть режим tamper resistant логов. Обычный текстових хаксор просто подрихтует. Да, ремотные сервера, бла-бла, но это сразу - другой уровень затрат и возни, с штатом админов или уймой нагрузки. А их tamper resistant работает и для локалхоста. И таки мешает хаксору подрихтовать лог задним числом. Его можно саботировать - но это будет опять же ЗАМЕТНО. Так что ситуации когда хаксор подрихтовал за собой и не оставил следов станет организовать значительно сложнее.
	Ответить | Правка | Наверх | Cообщить модератору

	80. "В systemd-journald спустя 6 лет признали проблему избыточной..."	–6 +/–
	Сообщение от Аноним (80), 15-Авг-26, 08:23
	Прощще переустановить, чем мутить эти логи, раз в миллион лет может быть баг, в 99% случаев ты и не знаешь что это, это может быть баг самого ядра, или какого то софта завязанного на systemd. Логи нужны разрабам. А то что вы разраб с opennet, сомневаюсь.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	101. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+2 +/–
	Сообщение от Аноним (101), 15-Авг-26, 10:42
	Логи нужны всем. Админ при настройке сервисов в логи смотрит в первую очередь. Есть системы автоматизированного анализа логов.
	Ответить | Правка | Наверх | Cообщить модератору

	178. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+1 +/–
	Сообщение от Аноним (174), 15-Авг-26, 16:51
	Вам же предыдущий автор дал прямую установку - админам локалхостов логи не нужны, им проще переустановить.
	Ответить | Правка | Наверх | Cообщить модератору

	223. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (223), 15-Авг-26, 21:43
	И как тебе стёртые логи на сломавшемся диске помогут расследовать что-то? Либо логи шлются в splunk (или что там вы любите), либо эти логи не особо-то и нужны.
	Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

	81. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (80), 15-Авг-26, 08:24
	>История тянется с марта 2020 года, когда в системе отслеживания ошибок был зарегистрирован отчёт, в котором было продемонстрировано, что генерирование около 500 КБ текстовых логов выливается в более чем 700 МБ физических операций записи на SSD. Разработчики systemd тогда наотрез отказались признавать проблему, ответили в стиле "вы не понимаете, как работают файловые системы", отказались от проведения профилирования и закрыли заявку с вердиктом "not actionable". Комментарии разработчиков собрали сотни отрицательных оценок от пользователей, однако позиция проекта осталась непреклонной. Это все капля в море. 700Mb логи. 5Гб Браузер. Поэтому держу браузер в psd profile-sync-daemon.
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	102. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от небесный ученый (ok), 15-Авг-26, 10:44
	> 5Гб Браузер. > Поэтому держу браузер в psd profile-sync-daemon. давненько тоже им пользовался, но отказался во первых, каждый раз при загрузке, время входа в акк увеличивается за счет доп.загрузки 5г с диска во вторых, это минус 5г ОЗУ, если у вас там 32г рамы то еще терпимо, но всё же это дофига в третьих, psd самую активную часть браузера - кэш, не тянет в ОЗУ, так как он располагаться отдельно от профиля браузера. кстати, из 5гу вас там 90% это хранящиеся локально данные с сайтов на которые уже скорее всего вы давно и не заходили, полезно порой чистить например через туже настройку браузера при этом, довольно редко но метко, с какого-то фига, частично обнулялся профиль браузера, после неудачной загрузки/перезагрузки системы. в общем, убрал нафиг, проблем больше чем пользы, а вместо этого просто смонтировал домашний кэш $HOME/.cache в tmpf, где хранятся кэши программы в том числе браузеров
	Ответить | Правка | Наверх | Cообщить модератору

	141. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (141), 15-Авг-26, 13:48
	Ниче там не увеличивается, профиль 340mb, из них overlay 40мб, то что реально пишется на диск, В противовес тем 5Гб кеша и всего такого когда заходишь на всякие WebUi сайты. Единственное что новая версия psd 7, глючит сохраняя профиль иногда в ядре 7 версии. Тоесть делает бекапы иногда и сбрасывает профиль. Это ктати дико бесит. От этого даже, лучше скажу что версия 6, на ядре 6 (*которая в Deb дистрах ), даже лучше. Хотя в 7й ничего прописывать даже ненадо, постаивил и оно работает. С этими лагами, но как то так. psd p browser/psname:  firefox/firefox owner/group id:  user/1000 sync target:     /home/user/.config/mozilla/firefox/tp3niiyp.default-release tmpfs dir:       /run/user/1000/psd/user-firefox-tp3niiyp.default-release profile size:    420M overlayfs size:  189M recovery dirs:   none Тут Overlay большой, но тк комп не выключался 3 дня.
	Ответить | Правка | Наверх | Cообщить модератору

	145. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (141), 15-Авг-26, 13:54
	UPD: а я понял, нет 5Гб не профиль, А кеш, я отключил, browser.cache.disk.enable = false Я имею ввиду когда просто запущщен браузер, он постоянно перезаписывает в профиле и в кеше, и за день накапливается 5Гб.
	Ответить | Правка | К родителю #102 | Наверх | Cообщить модератору

	239. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+1 +/–
	Сообщение от windows10 (ok), 15-Авг-26, 23:35
	> Это все капля в море. 700Mb логи. Ты очки-то протри, или понедельника дождись прежде чем комментировать. 700 Мб - это не размер лога, это количество записываемой информации на 500 Кб реального размера. Если ты не в курсе (а я больше чем уверен, что это так), то кроме твоих фельдиперцовых SSD на 100500 террабайт, есть еще такие носители информации как eMMC, NAND, да и MicroSD, которые представь себе, могут использоваться как накопители для embedded. Ну теперь хотя понятно почему этот ембеддед предпочитает взрослые системы типа freebsd, qnx или windows. Нужно быть полным имбцлом, чтобы на претензию "ваш продукт деградирует наш ссд" отвечать "not a bug".
	Ответить | Правка | К родителю #81 | Наверх | Cообщить модератору

	95. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+1 +/–
	Сообщение от небесный ученый (ok), 15-Авг-26, 10:12
	для журнала systemd можно прописать в конфиге что-бы любил только озу $ cat /etc/systemd/journald.conf Storage=volatile
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

	180. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (1), 15-Авг-26, 16:57
	Можно и так, но этот режим накладывает некоторые неприятные ограничения.
	Ответить | Правка | Наверх | Cообщить модератору

	193. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от небесный ученый (ok), 15-Авг-26, 18:02
	такие же как и при установке /var/log в tmpfs
	Ответить | Правка | Наверх | Cообщить модератору

	194. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (1), 15-Авг-26, 18:13
	Нет, не такие же. Storage=volatile запрещает использование неймспейсов у журнала, отчего например "journalctl --user" не будет работать.
	Ответить | Правка | Наверх | Cообщить модератору

	208. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от небесный ученый (ok), 15-Авг-26, 19:29
	для простых смертных это не страшно, всё можно будет найти в "общем" журнале, да и вроде как если напрямую указать в конфиге SplitMode=uid то поведение станет стандартным.
	Ответить | Правка | Наверх | Cообщить модератору

	219. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (1), 15-Авг-26, 20:58
	Нет, если Storage=volatile, то SplitMode=uid просто не имеет эффекта. В мануале все эти моменты описаны.
	Ответить | Правка | Наверх | Cообщить модератору

	197. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (1), 15-Авг-26, 18:15
	Ну и плюс туда гадит не только системда, а много чего еще. Автовынос мусора из tmpfs очень удобен.
	Ответить | Правка | К родителю #95 | Наверх | Cообщить модератору

	121. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (121), 15-Авг-26, 12:33
	Если, так сказать, технология отработана, то почему бы и нет?
	Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

3. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+6 +/–
Сообщение от Аноним (3), 15-Авг-26, 00:35
И года не прошло.. А хотя не, прошло) 6!
Ответить | Правка | Наверх | Cообщить модератору

	6. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+14 +/–
	Сообщение от Аноним (175), 15-Авг-26, 00:49
	А как пели: бинарный формат, это не партянки, всё быстро...
	Ответить | Правка | Наверх | Cообщить модератору

	12. "В systemd-journald спустя 6 лет признали проблему избыточной..."	–2 +/–
	Сообщение от Аноним (16), 15-Авг-26, 00:59
	>  А как пели: бинарный формат, это не партянки, всё быстро... А оно и правда - быстро. Скажем я могу более-менее в реальном времени парсить "все сообщения от sshd". Префильтр и индексированный доступ - обеспечит сам journald. И сообщение таки - можно атомарно читануть от и до. В текстовом же случае... 1) Вы вообще сами будете искать где граница между сообщениями. Мало того что это пригрузит проц - так вы еще и облажаться рискуете, когда атакующий в какой-нибудь юзернейм или что там 0x0d, 0x0a, 0x0 или что там воткнет - парсинг текста сорвется - и вы получите неполные или поддельные записи логов под контролем атакующего вообще. Что может быть использовано для обхода банов, крафтинга банов совершенно непричастным айпишникам и проч. 2) Парсинг гигз логов - нифига не быстро. А без этого - как вы вообще получите знание "сколько запросов с этого IP было за последние 5 минут"? Вот то то и оно - трекать такие вещи с текстовиками - потребует опять же юзать бинарные бд для всяких индексов - и вообще enterprise-grade soultion. Который настолько монструозен что будет у полутора коопрв. А доморощенные админы будут сиять голым окороком - доказывая что и так сойдет!
	Ответить | Правка | Наверх | Cообщить модератору

	30. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+4 +/–
	Сообщение от Аноним (30), 15-Авг-26, 01:48
	а зачем вам ssh в кровавом энткрпрайзе, он бай дизайн не предназначен для этого, для гигабайтов логов в том числе, iptables имеет все необходимое чтобы не грузить прикладную программу сетевым мусором, вы еще расскажите про фейл2бан, и как используете его чтобы защищаться от китайских ботнетов, его задача спасти ваш сервер городской поликлинники от разгневанного пациента. journald абсолютно ничем не лучше текстовых портянок, хотите нормальную защиту, отправляйте логи на удаленный сервер, который положит их в бд и проиндексирует для любых дальнейших манипуляций
	Ответить | Правка | Наверх | Cообщить модератору

	38. "В systemd-journald спустя 6 лет признали проблему избыточной..."	–2 +/–
	Сообщение от Аноним (-), 15-Авг-26, 02:33
	> а зачем вам ssh в кровавом энткрпрайзе, он бай дизайн не предназначен > для этого, для гигабайтов логов в том числе, У меня нет тех ваших энтерпрайзов и я не переклинен на этих кейсах. У энтерпрайзов свои проблемы, у меня свои. И мое отличие - у меня нет тимы фултайм энтерпрайз админов или желания им платить за то что я могу сам за пару часов решить - бесплатно по сути, почитав ман на апю sd. > iptables имеет все необходимое чтобы не грузить прикладную программу сетевым мусором, И конечно он сам поймает мне бота и по допустим URL запроса? Не дай боже еще и https? Или отстрелит бота пытающегося ломиться на конкретного юзера ssh которого у меня в системе точно нет и это точно сканнер-брутфорсер? И кстати у нас 2026 наступил и в моде так то - nftables. Которому я потом по итогам анализа команды и отдаю. Он умеет не только "ip sets" но еще и их авто-объединение и таймауты, допустим. Так что амнистию вообще не надо явно трекать. И диапазоны вредителей могут объединиться если это злая подсетка. Если уж мы о использовании фич ЭТОГО. > вы еще расскажите > про фейл2бан, и как используете его чтобы защищаться от китайских ботнетов, Я видел как работает fail2ban при этом vs огромные логи в текстовиках - и именно поэтому юзанул вон те апи. Так лучше работает. И отказываться от этого я не намерен. > его задача спасти ваш сервер городской поликлинники от разгневанного пациента. Чего? Кого? Поосторожнее там с проекциями. > journald абсолютно ничем не лучше текстовых портянок, А у меня - после использования его апи - совсем другое мнение на этот счет. > хотите нормальную защиту, отправляйте логи > на удаленный сервер, который положит их в бд и проиндексирует для > любых дальнейших манипуляций И тиму админов еще наймите на фултайм. Ничего нового в сказке про это все. А у меня вон то - ботов отстреливает. Само. С минимальной нагрузкой даже при app-level ddos. При минимальном моем участии в этом всем. И это все довольно эффективно и околореалтаймно. И юзает фичи nftables раз уж мы о птичках. Iptables - это для тех кто в XX веке застрял.
	Ответить | Правка | Наверх | Cообщить модератору

	134. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (30), 15-Авг-26, 13:24
	nftables абсолютно совместим с iptables, и лично мне привычнее вызывать его, iptables и ipset, можно еще tc, но это уже некст левел. > тиму админов еще наймите на фултайм поднять 1 сервер для логов - тима админов не нужна, это всего лишь 1 сервер который просто складывает строки в текстовички и зипует их каждую ночь, (вот вы еще доколупайтесь что не зипует, а gzip'ует), его  задача хранить логи за пару лет, чтобы можно было оценить обьем данных, чтобы можно было утверждать что вас действительно ктото целенаправленно брутфорсит последние пол года, а не голословно утверждать что Х запросов это брутфорс, потому что я так считаю. локальные логи это удобно, но ненужно, это понимаешь когда тебе сервер отформатируют в 0, у меня такой кейс был, (и у "хакеров" заведомо был доступ рутовый, это были свои, ну вот так вышло, была полиция, были разборки, было заведенное дело, была моя записка на имя директора о том что такое возможно за несколько месяцев, а лишних вопросов не было), но тем не менее, отдельный сервер уже промышленный стандарт, а жорналд - опоздал, там даже возможности поменять формат даты нету, ну комон, 2026 год, rsyslog попрежнему умеет больше и лучше, а банальный grep попрежнему удобнее, ну + сабж, ладно, переубедить когото в чемто в интернетах, это сомнительное, но я и не пытаюсь, просто указал вам на фатальный недостаток, а что с этим делать или не делать ваше ответсвенность
	Ответить | Правка | Наверх | Cообщить модератору

	150. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (150), 15-Авг-26, 14:08
	> nftables абсолютно совместим с iptables, Немного не так. Это superset. Я с nftables смогу все что вы с iptables - и намного больше. Но это вовсе не означает что вы с iptables сможете то же что я сделал с nftables. По этому поводу на данный момент iptables это такой shim над nftables для. > и лично мне привычнее вызывать его, iptables и ipset, можно еще tc, но это уже некст левел. Логика извозчика плюющегося на педали и руль вместо вожжей и "нопшла". А я изучил nftables малость - и смог куда более интересные вещи взамен. > поднять 1 сервер для логов - тима админов не нужна, это всего > лишь 1 сервер который просто складывает строки в текстовички и зипует > их каждую ночь, Во первых - если у меня был 1 сервер а стало 2 - это увеличение нагрузки вдвое. Во вторых - зипованые строки в текстовичках - не очень полезны в (около)реалтайм применениях. Т.е. если ко мне пачка ботов подвалила - я вон там "near realtime" их отстрелю и они после пары запросов - будут тестировать только drop пакетов ядром. Возможно со всей подсеткой. Вот это - может хоть полглобуса ломиться, не жалко. Они себя failed TCP connect якорят сильнее чем меня всем остальным. У них ресурсы сокетов надолго жрутся, а у меня для них stateless уже таки. > ктото целенаправленно брутфорсит последние пол года, а не голословно утверждать что > Х запросов это брутфорс, потому что я так считаю. Ну да, ну да, вот только в journald я для всех прог наситроил глобальный лимит журнала. > локальные логи это удобно, но ненужно, это понимаешь когда тебе сервер отформатируют > в 0, у меня такой кейс был, Локальные логи немного не для этого а для 1) Анализа системных проблем. 2) Идентификации аномальных состояний сервисов и диагностики. 3) Идентификации аномального использования сервисов и возможно парирования этого. > (и у "хакеров" заведомо был доступ рутовый, это были свои, ну вот так вышло, Если у хакеров был рутовый доступ - логично снять образ тазика на изучение а сам его перекатать с ноля. И кстати жирный централизованый сервак с логами - там разве что мишень еще краской нарисовать, для совсем непонятливых... :) И кстати а где же пафосныуе ластики и прочие графаны? Энтерпрайз булшит имени "free" "hck" вам не зашел? Вы решили возвести свои педали на новый уровень? :) > директора о том что такое возможно за несколько месяцев, а лишних > вопросов не было), но тем не менее, отдельный сервер уже промышленный стандарт, Я сам себе - стандарт. И хочу чтобы мои хосты были более-менее самодостаточными. Ессно где мне сильно надо - там и форвард логов есть. Порой - вот - после активных префильтров :) > а жорналд - опоздал, там даже возможности поменять формат даты нету, Там можно - написать в два счета свой фетч сообшений из базы, почитав ман (по моему там даже пример простого дампера всех логов есть в мане), и рисовать любой формат даты по СВОЕМУ вкусу. Все что сможете напрограмить. А если вам вот этот формат не нравится - завтра пропатчил чтеца и теперь формат другой. А внутренний формат хранения времени вообще ни о каких форматах ничего не знает. Ибо хранить надо данные - а не их представление, внезапно! А теперь попробуйте сменить формат даты вот этому гигазу текстовых логов на что-то иное, если старый вам не нравится... или к вопросу о том почему надо хранить данные а не их представление и их форматирование... > а банальный grep попрежнему удобнее, ну + сабж, ладно, переубедить когото > в чемто в интернетах, это сомнительное, но я и не пытаюсь, > просто указал вам на фатальный недостаток, а что с этим делать > или не делать ваше ответсвенность Внезапно grep можно и на вывод journalctl натравливать. С его характерной "эффективностью по ресурсам" конечно. Но внутренние префильтры зело эффективнее, там так то - индексы и проч есть на некоторые вещи. Вы ж не думали что оно раздувает запрос на запись чисто по приколу? :)
	Ответить | Правка | Наверх | Cообщить модератору

	44. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (175), 15-Авг-26, 03:11
	Если ты в риалтайме парсишь гигзы логов от ssh... Что-то ты неправильно делаешь.
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	106. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+1 +/–
	Сообщение от Аноним (106), 15-Авг-26, 11:04
	> Если ты в риалтайме парсишь гигзы логов от ssh... Что-то ты неправильно > делаешь. Вот теперь я все делаю правильно: 1) Сообщение приходит мне вскоре после того как его сгенерил sshd. 2) Я уверен что я более-менее up to date и состояние трекера гамнюков - правильное. 3) Если это не так я могу отмотать на "10 сообщений sshd назад" или "полчаса до" и парснуть только - 10 сообщений sshd, перестроив состояние трекера гамнюков при "нулевом" старте, если это было надо. 4) И кстати в случае апей - journald при получении сообщения видит sizeof(сообщения). И потом при вызове через апю - мне его отдаст с этим sizeof :). Атакующий может хоть на ушах стоять пытаясь сорвать парсинг - но я получу ВСЕ сообщение, с правильным size of :). И дальше - если я в курсе что это 1 мсг и там 0x0d, 0x0a и прочие 0x00 - алилуя, мы можем бонусом палить кулхацкеров одной левой. И сразу выписывать жесткий длинный автобан на айпи с которого сие пришло. Нехай новый проксик ищет :)
	Ответить | Правка | Наверх | Cообщить модератору

	50. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от вымя (?), 15-Авг-26, 03:47
	> Скажем я могу более-менее в реальном времени парсить "все сообщения от sshd". Префильтр и индексированный доступ - обеспечит сам journald. А теперь попробуй то же самое с cron-задачами. Нет, -u crond и прочие вариации не подходят, потому что красношляпые гении решили, что на каждый запуск задачи нужно плодить одноразовые session-c31337.scope. В итоге опять грепаем, только не из файла, а через, ээээ, пайпы. Очень удобно.
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	55. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (55), 15-Авг-26, 04:14
	Для вас придумали таймеры
	Ответить | Правка | Наверх | Cообщить модератору

	69. "В systemd-journald спустя 6 лет признали проблему избыточной..."	–1 +/–
	Сообщение от вымя (?), 15-Авг-26, 06:21
	...которые в логе вообще не отсвечивают. Вот где в журнале написано про запуск dnf-makecache.timer? А он запустился, вон, свежие следы в /var/cache лежат! «Неудобно работать с логами? Просто выкиньте их!» Гениально. В таймерах этих ещё и stdout/stderr без костылей не попадает ни в хвалёный journald, ни на почту. Свои-то файлы мне, может, и не жалко подпереть, но вот следить за миллионом дистрибутивных файлов для того, чтобы обставлять их override-ами, желания нет никакого. Но вы, конечно, не прекращайте восхищаться гением Лёни, подарившему админам локалхостов многословный ароматизатор crontab, не идентичный натуральному.
	Ответить | Правка | Наверх | Cообщить модератору

	110. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+2 +/–
	Сообщение от Аноним (-), 15-Авг-26, 11:27
	> ...которые в логе вообще не отсвечивают. Вот где в журнале написано про > запуск dnf-makecache.timer? А он запустился, вон, свежие следы в /var/cache лежат! Вот кстати верно подмечено - от системд меньше тупого технического спама каждый (час минуту месяц год день, ... ). Не, мне совершенно не интересно как там кронд логинился чтоб проверить не пора ли запустить. Совсем. Это просто бесполезный повторяющийся спам в логах. > «Неудобно работать с логами? Просто выкиньте их!» Гениально. А таки в sd через апю с логами работать куда как удобнее чем с текстовиками. Это нечто типа indexed DB где record - интересовавшее сообщение. Можно итерировать вперед-назад (оперируя сообщениями целиком, а не "строками"), адресоваться в энную точку времени, не говоря о вещах типа префильтра что это юнит условный nginx.service - и более нифига, так что дальнейший парсер может быть уверен что это - от nginx, не заморачиваясь знанием как парсить еще и от sshd допустим. Вдруг я автоотстрел applevel ddos для нжинкс писал? Зачем мне sshd парсить при этом? Вон то избавляет от ряда нежданчиков и паразитной нагрузки. > В таймерах этих ещё и stdout/stderr без костылей не попадает ни в > хвалёный journald, ни на почту. Логи надо было смотреть - у юнита который .timer активирует. Это же элементарно, Ватсон. Сам .timer это лишь лайтовая пометка настраивающая вон тому .service периодику. > жалко подпереть, но вот следить за миллионом дистрибутивных файлов для того, > чтобы обставлять их override-ами, желания нет никакого. Да вот знаете, если сравнить - с кроном при прочих равных еще больше грабль, в том плане что если такие оверрайды понадобятся - еще и попробуй угадай, грохнет тебе в энном дистро их потом пакетник или нет?! В sd хоть регламенты деления на "system" и "admin" есть, и все сразу по полочкам. Дефолты - тут, оверрайды - тут, и пакетник не трогает оверрайды админа вот хоть там что. А с кроном и прочими логротейтами - угадай вообще как это обыграет пакетник конкретного дистро, и какая участь ждет мои оверрайды вдолгую, угумс. > Но вы, конечно, не прекращайте восхищаться гением Лёни, подарившему админам локалхостов > многословный ароматизатор crontab, не идентичный натуральному. Гений Леня - решил более 9000 дурных системных проблем на которые вы иои просто забивали рассказывая как мне это "не надо" или - сватали огромные энтерпрайзные монстры. Довольно плохо жить в мире где есть только скворешник в поле и лопухи как туалетная бумага vs огромная мега-фабрика занимающая полпланеты, где вы спустите все ресурсы на и отстаток жизни на тщетные попытки ее вообще обслужить - без каких либо опций "in between".
	Ответить | Правка | Наверх | Cообщить модератору

	164. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от freehck (ok), 15-Авг-26, 15:42
	> Вдруг я автоотстрел applevel ddos для нжинкс писал? Ага, ага. А на сходку реконструкторов ты наверное пойдёшь в кепке, да? Не потому, что её козырёк защищает от удара мечом, а потому, что ты просто в него веришь? =) > попробуй угадай, грохнет тебе в энном дистро их потом пакетник или нет?! Лол, они вообще ничему не учатся. За столько лет — и всё те же самые глупости. Что ж, проучим убогих just for lulz. Сделаю-ка я запрос в поисковичке... Итак! =) 2024й: https://www.opennet.ru/openforum/vsluhforumID3/135550.html#192 > Не "хрен его знает перетрут его потом или нет", а точно нет. Что в rpm-, что в deb-пакетах есть такая вещь, как "конфигурационные файлы". За подробностями -- велкам в 5ю главу maint-guide для deb, читать про conffiles; для rpm -- читать doc по spec, в частности про %config и %config(noreplace). И отдельно, чтобы сразу при прочтении имели в виду: файлы в /etc получают эти флаги автоматом. 2023й: https://www.opennet.ru/openforum/vsluhforumID3/ubb/131286.ht... > debhelper при сборке пакета помечает все файлы в каталоге /etc как конфигурацинные. Конфигурационные файлы при установке нового пакета -- не замещаются 2016й(!!!): https://www.opennet.ru/openforum/vsluhforumID3/108006.html#274 > в Debian для сборки пакетов используется роскошный набор скриптов debhelper, один из которых (dh_installdeb) автоматически помечает все файлы пакета, находящиеся в /etc как конфигурационные, и потому затереть их так просто не выйдет Вы 10 лет подряд не учитесь и повторяете одни и те же глупости про "замещение файлов при обновлении пакета". И вы ещё удивляетесь, почему над вами все смеются? =) > Гений Леня - решил более 9000 дурных системных проблем на которые вы иои просто забивали Да не было у нас этих проблем, говорим же: не было их у нас! Лёня в носу поковырял, придумал проблемы, написал пространные статьи о них, а затем героически решил. Он просто расходы перед инвесторами обосновывал, а вы всё за чистую монету принимаете. =)
	Ответить | Правка | Наверх | Cообщить модератору

	181. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (-), 15-Авг-26, 17:01
	Для сэра freehck: вы бы определились? Если вы не даете анонимам отвечать, то зачем инициируете дискуссии с анонимом? Вас так припекло что вы не смогли пройти мимо? ИМХО, в опенсорсе не место вашим менторским монологам. Это страшно далеко от открытых взаимодействий. Ваши попытки заменить технологии и обсуждения абузом полномочий и политикой - явно не про опенсорс. И на примере всяких пох, нах, умок и прочих можно было бы уже и догадаться куда вас этот вэй приведет. А теперь по делу: > Ага, ага. А на сходку реконструкторов ты наверное пойдёшь в кепке, да? Ежели я ильича косплею - кепка просто масткэвище! Вы ж не уточняли детали :) > Не потому, что её козырёк защищает от удара мечом, Зато я усвоил что такие как вы - ножик в спину всегда воткнут. Усложняя жизнь на ровном месте сказками про вэи и парадигмы с одной стороны, а потом свинтив на винду или мак с какими-нибудь благовидными отмазками. А я что хочешь то и делай. Либо пробивай все стены своим лбом с неэффективной технологией либо проприетарщику сдавайся. И тут вдруг оказывается что есть пути лучше, на ваше несчастье... :) >> попробуй угадай, грохнет тебе в энном дистро их потом пакетник или нет?! > Лол, они вообще ничему не учатся. За столько лет — и всё те же самые глупости. Что ж, проучим убогих just for lulz. Сделаю-ка я запрос в поисковичке... > Не "хрен его знает перетрут его потом или нет", а точно нет. Что в rpm-, что в > deb-пакетах есть такая вещь, как "конфигурационные файлы". За подробностями -- > велкам в 5ю главу maint-guide для deb, читать про conffiles; для rpm -- читать doc > по spec, в частности про %config и %config(noreplace). Мне проще почитать 1 регламент на системду - и понять что во ВСЕХ дистро с sd будет - ТАК. Это сильно уменьшает обьем чтива и вообще убирает допущение что это deb, rpm или что там еще. Это "any distro with s-d". Мне теперь вообще не надо знать как их пакетник работает с точки зрения что dev что adm. Полностью декоррелировано, в отличие от. > debhelper при сборке пакета помечает все файлы в каталоге /etc как конфигурацинные. > Конфигурационные файлы при установке нового пакета -- не замещаются Вы не понимаете. Недостаток вашего подхода в том что он требует знания кучи грабельных деталей. Конкретного дистро. Это в РАЗЫ больше чтива, и отличается по дистрам. В этом смысле поттеринг гений - минимизировал знание и сделал его реюзабельным. Прочитав 1 компактный ман можно девелопать или эксплуатировать любой дистр с sd. Эврика! > Вы 10 лет подряд не учитесь и повторяете одни и те же глупости про "замещение > файлов при обновлении пакета". И вы ещё удивляетесь, почему над вами все смеются? =) В этом мире слишком много знаний - поэтому я изучаю только ценные и реюзабельные. И чем меньше этого cruft в моей голове - тем лучше моя жизнь. Потому что это знание - и не мировая константа, и не реюзабельно, и не ведет к реализации проектов и идей, а лишщь подгружает меня всякой рутиной и ненужным хламом. SD в этом смысле напротив сильно заоффлоадил меня от кучи таких вещей. > Да не было у нас этих проблем, говорим же: не было их у нас! Это надо повторять засев в телевизоре, попросив паству взять банку с водой. Но на меня это не работает. И я не собираюсь выбирать между педальным логингом в текст и энтерпрайзным ластиком когда оказывается есть и опции in between. Мне вот так - больше по вкусу. Живите теперь с этим. > Он просто расходы перед инвесторами обосновывал, а вы всё за чистую монету принимаете. =) Я сам себе инвестор, вот какая незадача. И мой интерес чтобы ROI был повышще, TCO пониже, а на концептуальном уровне - знания были ценными и реюзабельными. А вот лично вы перестаньте врать хотя-бы самому себе. Глядишь и более стройная картинка мира сложится. Без таких глупых проекций. В моем мире все просто. Что помогает забацать проекты - хорошо. Что мешает - препятствие, оно должно быть устранено. Типы пытающиеся мне втирать из макоси за то как должно быть в линух - явно мне не помощники. А вот препятствия - пожалуй. Так что с моей стороны есть спрос на иное устройтсво мира. Без вас.
	Ответить | Правка | К родителю #110 | Наверх | Cообщить модератору

	233. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от вымя (?), 15-Авг-26, 22:51
	> Логи надо было смотреть - у юнита который .timer активирует. Это же элементарно, Ватсон. Только их ни у какого юнита нет. Вообще. Хоть весь journalctl -S 00:00 перечитайте. И, нет, команда, запускаемая из .timer, не уходит в молчанку, если оторвать её от tty, это уже проверялось. > Дефолты - тут, оверрайды - тут, и пакетник не трогает оверрайды админа вот хоть там что. Только они всё равно не помогают в ситуации, когда нужно с обновлённым пакетом приезжает изменившийся ExecStart. > решил более 9000 дурных системных проблем s/решил/создал/. Вечно вляпываешься в какие-то мелочи, то в жор процессора journald-ом, то в поломанный резолвинг dns, то в waiting 99999999s for чототам.mount при ребуте (чего ты там ждёшь, а, уже давно нет процессов, открывавших там файлы), то в необходимость оборвать все сессии logind только потому, что он долгое время настройку про поведение на закрытие крышки ноутбука мог менять только полным своим перезапуском. А там, где действительно было бы полезно выкинуть обратную совместимость для общего блага (например, отказаться от поддержки pid-файлов самодемонизирующихся процессов), они почему-то, наоборот, продолжают носить поддержку с ненадёжными костылями. Удивительно, как они умудряются выбирать плохие решения и там, где всё сознательно ломают, и там, где стараются не ломать.
	Ответить | Правка | К родителю #110 | Наверх | Cообщить модератору

	241. Скрыто модератором	+/–
	Сообщение от Аноним (-), 16-Авг-26, 00:07
	> Только их ни у какого юнита нет. Вообще. Хоть весь journalctl -S > 00:00 перечитайте. И, нет, команда, запускаемая из .timer, не уходит в > молчанку, если оторвать её от tty, это уже проверялось. Шутить изволите? Подправил для теста первый дебианский таймер+сервис подвернувшийся под руку и сунул сие в /etc (к вопросу о удобстве адин оверрайдов), после чего немедля поимел в логах ЭТО: Aug 15 23:29:33 testvm2 systemd[1]: Starting dpkg-db-backup.service - Daily dpkg database backup service... Aug 15 23:29:33 testvm2 sh[84379]: abc def dpkg-db-backup Aug 15 23:29:33 testvm2 systemd[1]: dpkg-db-backup.service: Deactivated successfully. Как вы поняли я лишь: 1) Сменил в стандартном дебианском .timer тип на minutely, просто чтоб не ждать дофига. 2) Добавил ExecStartPre=/usr/bin/sh -c 'echo ... ' чтоб протестировать логинг ругани, именно из юнита, именно в stdout. 3) Сделал systemctl daemon-reload чтоб все сие подхватить. Вывод моего юнита прекрасно кажется journalctl -a -u dpkg-db-backup (или dpkg-db-backup.service). В чем проблема? Если какие-то более продвинутые программы - там обычно можно явно настроить логинг в сислог, и даже как правило указать имя для сислога. Сие тоже - поле sd журнала, и тоже юзабельно для префильтра так то. Де факто часть фишек journalctl лишь "юзерский фронтэнд" к journal API и можно это программно подергать более предметно если надо какой-то процессинг логов. При открытии потока к журналу можно префильтр вкатить на то что допустим только такой-то unit. Или такое-то имя сислога. Или что там еще. То что вы не умеете юзать sd и где-то накосячили - увы, я не буду начитывать вам бесплатный базовый курс или узучать где вы профакались, смотрите как другие юниты сделаны или читайте маны сами. Или спросите гугла в режиме AI - накидает примеров и гайд даст как юзануть, с него станется. Нашару, без смс. > Только они всё равно не помогают в ситуации, когда нужно с обновлённым > пакетом приезжает изменившийся ExecStart. Этот ExecStart приедет в /usr. А если я админ и перекрыл тот юнит своим, в /etc, как в примере выше, уже как-то пофиг что приехало в /usr. Вообще совсем. И в sd этот регламент - везде. Поэтому мне с точки зрения девелопа и наруливания старта - не надо знать теперь - какой у вас пакетник и как он работает. Этот регламент поддерживается - всеми кто sd юзает. Договоренность такая, дефолты системы/программы в /usr, оверрайды в /etc. Админское в /etc имеет приоритет. Так что обзаменяйетсь usr до упаду, он при наличии /etc варианта не у дел. >> решил более 9000 дурных системных проблем > s/решил/создал/. Вечно вляпываешься в какие-то мелочи, то в жор процессора journald-ом, А вон те зиллионы проблем почему-то несчитово было. Ну и тут видимо дело в совпадении радиуса рук с технологией. Мой норм совпал. > то в поломанный резолвинг dns, Я вообще не юзаю networkd. Это вообще весьма опциональная штука. То что я юзаю sd != юзаю networkd. > при ребуте (чего ты там ждёшь, а, уже давно нет процессов, Unit - не синоним активного запущенного процесса(-ов). Про какой-нибудь RemainsAfterExit вы видимо тоже не слышали. Т.е. юнит может считаться запущенным - при 0 активных процессах. Я так сделал например кастомный своп-в-zram. Его start наруливает активацию сего, stop - деактивирует. Пока он "started" оно кажется как активный юнит в списке sd, я в курсе что фича активна. Но этому не соответствует ни 1 активный процесс. Это трекинг состояния фичи для целей менеджмента. При шатдауне системы оно кроме всего прочего и его в stop отправит - корректно отцепив все это без спецэффектов. > было бы полезно выкинуть обратную совместимость для общего блага (например, отказаться > от поддержки pid-файлов самодемонизирующихся процессов), они почему-то, наоборот, продолжают > носить поддержку с ненадёжными костылями. Потому что одномоментно ВСЕ программы и их обвес переписать - несколько опаньки, а всем надо чтобы работало - и желательно еще вчера. Но поддержку sysv они таки - выпилили в свежих версиях вроде как. Я про те чудесатые генераторы sysv портянки -> виртуальные .service. > Удивительно, как они умудряются выбирать плохие > решения и там, где всё сознательно ломают, и там, где стараются не ломать. Как по мне - в целом у них достаточно разумные соотношения и если просто сравнить с другими - то сравнение запросто в пользу sd может выйти. Более того сравнимые вещи типа launchd и SMF бывают еще более странные и оверинженернутые. Типа каого-нибудь монструозного XML - но не знаете, он тормозит, так что вот еще вам кеш этого в скулайт. А, почти регэдит - только еще болеее через гзоппу?! Когда вот тут монструозный XML, но еще есть бинарный кеш представления оного и надо еще синхронизацию оных чекать? На этом фоне sd не такой уж и плохой :))
	Ответить | Правка | Наверх | Cообщить модератору

	108. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+1 +/–
	Сообщение от Аноним (-), 15-Авг-26, 11:16
	> А теперь попробуй то же самое с cron-задачами. Нет, -u crond и > прочие вариации не подходят, Поэтому... 1) Я снес cron нахрен и забыл про него и его дурной спам логинами в логи как страшный сон. 2) С systemd-timers и юнитами, таки, префильтр - норм работает. 3) Это все кстати позволяет атрибутить все логи, лимиты ресурсов и проч - не "крону" а "конкретному юниту". 4) И в отличие от крона - сразу виден статус этого всего. Если юнит пускаемый по таймеру завалился это в systemctl видно так то. А вот как это в кроне вообще трекаете вы? > потому что красношляпые гении решили, что на > каждый запуск задачи нужно плодить одноразовые session-c31337.scope. Я решил эту проблему - полным переводом моих систем на systemd.timers :) > В итоге опять грепаем, только не из файла, а через, ээээ, пайпы. Очень удобно. Ничего я уже не грепаю, сугубо префильтры, можно прям по именам юнита. Для таймеров и ассоциированных с ними юнитов это все тоже на отлично работает. И заодно статусы юнитов - как на ладони. А у вас - кронджоб завалится а заметите вы это только через неделю. Может быть. Когда кто-то до саппорта доорется, место кончится, или еще что-то критичное и фатальное случится. Всякие logrotate и жор места логами - туда же, кстати! В sd можно нарулить макс. размер логов и он будет кольцевым буфером по сути. И не превысит сие. Без делания мозга прописыванием каждой микропакости в logrotate и окончания места спустя неочевидный интервал времени при малейшей лаже в 100500 сервисах и их параметрах.
	Ответить | Правка | К родителю #50 | Наверх | Cообщить модератору

	235. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от вымя (?), 15-Авг-26, 22:57
	> 2) С systemd-timers и юнитами, таки, префильтр - норм работает. см. #233 > И в отличие от крона - сразу виден статус этого всего. > А у вас - кронджоб завалится а заметите вы это только через неделю. Мне от крона письмо на почту приходит, а статусы юнитов у вас кто мониторит? Вы сами-то status наверняка запускаете только когда «кто-то до саппорта доорется», не говоря уже об алертах в прометеях или хотя бы заббиксах :-)
	Ответить | Правка | Наверх | Cообщить модератору

	242. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (-), 16-Авг-26, 00:26
	> см. #233 UNCONFIRMED. Я не понимаю вашу проблему, у меня все работает, не поленился простой тестик сделать из подвернувшегося юнита с таймером в дебиан (бот свирепый скрыл, жмите ответить, увидите). > Мне от крона письмо на почту приходит, Окей, круто, а для старта и стопа того что ВНЕ крона - так же? Или как обычно куча всякого добра в куче разных мест? По разному? Без overview состояния системы в целом? Или почему меня именно крон отдельно от остальной системы волновать должен вообще? > а статусы юнитов у вас кто мониторит? Да кто угодно по вкусу. Можно даже сделать аналогичный вашему фич, пиная таймером сервис который пинает systemctl и смотрит интересовавшее допустим. Но можно и более мощно, например - указать вон тот юнит - как обработчик запускаемый при фэйле вон того юнита. При этом можно довольно легко сделать "mission control", т.е. осмысленную реакцию системы на сбой "критичных сервисов". В свое время Nokia делала это отдельным сервисом, потому что upstart юзаемый ими так не умел. Поцтера эмбедеры попросили - и появилось это. А также всякие вачдоги процессов уровня апи и нотификации старта сервисов. Суммарно sd - мощный superset фич того что было до него. Им можно сделать все вон то - и намного больше. И детальнее. При том не выписывая это самому. > Вы сами-то status наверняка запускаете только когда «кто-то до > саппорта доорется», не говоря уже об алертах в прометеях или хотя бы заббиксах :-) Наиболее интересные вещи мне таки пришлют алерты в месенжер (tox). Потому что я до кучи еще и ботов для оного кодить научился, оно и спамит меня тем на что я подписался. Что на комп, что на мобилу. Best of all? Это не завиасит от живости 1 конкретной системы - и 3rd parties как таковых. А даже эти ваши жабиксы мне малость избыточны, я больше всего по эмбедовке прусь. А вот более системные вещи sd мне очень в тему пришлись.
	Ответить | Правка | Наверх | Cообщить модератору

	54. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от freehck (ok), 15-Авг-26, 04:13
	> В текстовом же случае... > 1) Вы вообще сами будете искать где граница между сообщениями. Зато это хоть возможно будет сделать. Вот рубанёт тебе питание, журнал окажется повреждён — и удачи тебе найти границу между сообщениями: потеряешь как минимум последние 5 минут (ибо именно с такой периодичностью индекс полей сбрасывается в журнал journald), а потенциально и весь журнал (если вдруг рубануло в момент fsync-а индекса). В случае же старого доброго текстового формата, если оно записалось — значит записалось, и будет доступно для анализа, когда потребуется. > 2) Парсинг гигз логов - нифига не быстро. А без этого - как вы вообще получите знание "сколько запросов с этого IP было за последние 5 минут"? Вот то то и оно А когда это journald научился строить индексы по кастомным пользовательским полям, да ещё и с высокой кардинальностью? Вот это новость! =) Впрочем, ты конечно извини, но пример у тебя — из разряда хотелок админов локалхоста. На проде для такой аналитики используются clickhouse и elasticsearch, а уж никак не grep, и уж тем более не journalctl. А на одиноком локалхосте — не всё ли блин равно?
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

	94. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от фняк. (?), 15-Авг-26, 09:58
	Разворачивать кх или эластик ради пятка хостов(возможно виртуалок) как-то оверкилл
	Ответить | Правка | Наверх | Cообщить модератору

	112. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+1 +/–
	Сообщение от Аноним (-), 15-Авг-26, 11:40
	> Разворачивать кх или эластик ради пятка хостов(возможно виртуалок) как-то оверкилл У этих господ есть только 2 градации: 1) Удобства во дворе, когда, таки, до того как подтереть зад - надо, оказывается, самому сгонять в лес, нарубить деревьев, сварить целлюлозу, раскатать в бумагу, построив первобытную фабрику .... ну или, вот, лопухи, если лето, надергал и порядок. Подумаешь, окорок стал зеленый. А зимой вообще окорок мерзнет, но упоминать это нельзя - контрить ведь нечем. 2) Хардкорный энтерпрайз со всеми их е...чими оверинженернутыми ластиками и прочей оверинженернутой энтерпрайз пакостью.  На фоне которой системд и журналд - невинные детские шалости. Которые в отличие от - не требуют тиму фултайм админов на обслуживание этой штуки, ее баз, сервера(ов), и чего там блин еще. А еще - я усвоил что чем напышеннее и более менторски кто-то себя ведет, не утруждаясь аргументацией, тем меньше его следует слушать. Freehck в этом смысле взял 10 из 10 запретив ответы на свои сообщения. Так что вы можете читать его "гениальный" монолог, ничем не подпертый технически :). За такие соотношения его будушее будет столь же эпично как и похов-нахов, собственно. Не, пользователи макоси не будут диктовать нам что должно быть - в линухе.
	Ответить | Правка | Наверх | Cообщить модератору

	135. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (135), 15-Авг-26, 13:26
	> Разворачивать кх или эластик ради пятка хостов(возможно виртуалок) как-то оверкилл Да что вы хотите от типа с макосью? Он линух вообще для себя не юзает - но из своей макоси будет нам транслировать как у нас "должно" быть. Сам он свои пирожки кушать конечно же не будет, делегировав эпплу полномочия знать лучше.
	Ответить | Правка | К родителю #94 | Наверх | Cообщить модератору

	159. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от freehck (ok), 15-Авг-26, 14:58
	> Разворачивать кх или эластик ради пятка хостов(возможно виртуалок) как-то оверкилл Да, конечно оверкилл. Но я про 5 виртуалок и не говорил: 5 виртуалок — это не прод, это просто 5 отдельных локалхостов, и администрируются они сообразно локалхостам. А на локалхосте, опять же — вообще однофигственно, как с логами взаимодействовать. Тут кстати можно провести параллель со старым философским вопросом о том, после какого количества сложенные вместе песчинки являются кучей: после какого количества машин, кучка локалхостов превращается в полноценный прод? (параллель, конечно, не корректная, потому что вовсе не от количества машин это зависит, а скорее от уровня достигнутой отказоустойчивости — но тем не менее, аналогия весьма забавная) PS: Подумать только, как же пригорает у анонимов ниже =)
	Ответить | Правка | К родителю #94 | Наверх | Cообщить модератору

	177. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от User (??), 15-Авг-26, 16:50
	Ээээ... ну, эластик с кликом может и да, а вот prometheus-grafana-loki одним observability-stack'ом вполне себе ложится. Есть-пить особо не просит, а управляемость проектом повышает прям значительно.
	Ответить | Правка | К родителю #94 | Наверх | Cообщить модератору

	184. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (-), 15-Авг-26, 17:23
	> Ээээ... ну, эластик с кликом может и да, а вот prometheus-grafana-loki одним > observability-stack'ом вполне себе ложится. Есть-пить особо не просит, а управляемость > проектом повышает прям значительно. Ну да, по сравнению с journald то - жрущим пяток мегабайт на все и 1 процесс, довольно эффективной и простой апей, где минимальный чтец логов требует аж libsystemd - и более нифига ... прямо изящное системное решение с минимом зависимостей, что уж там. (just f...g die, enterprise b*tch)
	Ответить | Правка | Наверх | Cообщить модератору

	206. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от User (??), 15-Авг-26, 18:59
	>> Ээээ... ну, эластик с кликом может и да, а вот prometheus-grafana-loki одним >> observability-stack'ом вполне себе ложится. Есть-пить особо не просит, а управляемость >> проектом повышает прям значительно. > Ну да, по сравнению с journald то - жрущим пяток мегабайт на > все и 1 процесс, довольно эффективной и простой апей, где минимальный > чтец логов требует аж libsystemd - и более нифига ... прямо > изящное системное решение с минимом зависимостей, что уж там. > (just f...g die, enterprise b*tch) Ну и скачи потом по всем хостам в поисках "а на какой же ноде этот вот запрос отработал?!" - о метриках работы приложения и минимальной предикативке - вовсе не говорю, лошадка такого не умеет - ямщику и не надоть, понапридумывают, ишь, рельсы всякие с еропланами - только бы лошадков не заводить...
	Ответить | Правка | Наверх | Cообщить модератору

	212. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (212), 15-Авг-26, 19:57
	> Ну и скачи потом по всем хостам в поисках "а на какой > же ноде этот вот запрос отработал?!" - Если это и правда важное - хост может с своей стороны инициировать алерт мне. Да, представляете, жирная централизованая точка отказа вида "большому кораблю большая торпеда" - не есть mandatory. Future is Distributed. Но лучший хост - тот который я не вижу и не слышу и все просто работает. К чему я и стремлюсь. > о метриках работы приложения и минимальной предикативке - вовсе не говорю, В моем мире лучший компьютер - который помогает мне в моих целях и задачах, и который я без нужды просто не вижу. Поэтому мне в 99% до 3.14ды все ваши суперсеие метрики и софт который создает больше проблем чем решает. Представляете? Мы оперируем в сильно разных парадигмах. И последний у кого я буду учиться айти - это клиент Accenture. Ибо я в курсе кто это такие и где ваше место в суммарной пищевой цепочке. А моя цель - быть в совсем иных местах этой пищевой цепи. Да и задачи и хотелки у нас - сильно разные. > лошадка такого не умеет - ямщику и не надоть, понапридумывают, ишь, рельсы > всякие с еропланами - только бы лошадков не заводить... Как же не умеет? Конка - и лошадки, и рельсы :). Да, странноватый гибрид - но был же.
	Ответить | Правка | Наверх | Cообщить модератору

	224. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (223), 15-Авг-26, 21:47
	Опять какие-то локалхостные истории о защите копеечного впс от китайских ботнетов. > сколько запросов с этого IP было за последние 5 минут Кому это вообще может быть интересно? Всё, что меньше 100 rps не интересует.
	Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

4. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+5 +/–
Сообщение от Аноним (4), 15-Авг-26, 00:35
А я думал это норма, что что все эти лог журналы насилуют твой ссд, чтобы потом форензик экспертам было легче копаться в твоих штанах.
Ответить | Правка | Наверх | Cообщить модератору

	8. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+1 +/–
	Сообщение от Аноним (-), 15-Авг-26, 00:52
	>  А я думал это норма, что что все эти лог журналы насилуют твой ссд, > чтобы потом форензик экспертам было легче копаться в твоих штанах. Да не парься ты так - форенсики с твоего SSD и с якобы-in-place файлухи вынут кучу данных с твоего SSD. Потому что флеш память не умеет in place перезаписи, внезапно. А стирание медленное и крупноблочное. Так что контроллер - всяко почти наверняка CoW сделает. И если читануть NAND напрямую без его услуг по пропуску лишнего... Кстати, "secure" erase с явным протиранием нулями региона - тоже так не сработает. Оно протрет нолями ДРУГОЙ регион SSD. Вот явный запрос TRIM конкретного региона - еще может какую-то пользу принести. Только это блочный уровень, ФС сами по себе без явного прокостыливания такими вещами не оперируют.
	Ответить | Правка | Наверх | Cообщить модератору

	56. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+1 +/–
	Сообщение от Аноним (55), 15-Авг-26, 04:20
	> ФС сами по себе без явного прокостыливания такими вещами не оперируют. -o discard делает ровно это
	Ответить | Правка | Наверх | Cообщить модератору

	113. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+1 +/–
	Сообщение от Аноним (-), 15-Авг-26, 11:41
	>> ФС сами по себе без явного прокостыливания такими вещами не оперируют. > -o discard делает ровно это Добро пожаловать в мир явного прокостыливания. И даже так это все - delayed по соображениям эффективности, и без каких-то жестких гарантий.
	Ответить | Правка | Наверх | Cообщить модератору

	238. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (55), 15-Авг-26, 23:33
	> delayed по соображениям эффективности Ну -o sync какой-нибудь, но ты сам не захочешь этим пользоваться.
	Ответить | Правка | Наверх | Cообщить модератору

	243. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (-), 16-Авг-26, 00:31
	>> delayed по соображениям эффективности > Ну -o sync какой-нибудь, но ты сам не захочешь этим пользоваться. Вы видимо не в курсе что DISCARD - это лишь _хинт_ фирмваре накопителя о том что регион не используется. Он не обязывает фирмвар пойти и физически уничтожить эти данные. И что там реально здоровый блоб фирмвары сделает получив эти команды - вообще сильно отдельный вопрос.
	Ответить | Правка | Наверх | Cообщить модератору

	97. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Вася (??), 15-Авг-26, 10:21
	поэтому шифрование на носитель и норм. Но вообще можно просто мусором забить разочек.
	Ответить | Правка | К родителю #8 | Наверх | Cообщить модератору

	114. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (-), 15-Авг-26, 11:42
	> поэтому шифрование на носитель и норм. Но вообще можно просто мусором забить > разочек. О ситуации когда форенсик или кто там смог прорубиться в работающую систему и снять дамп и/или ключи оттуда - мы подумаем немного потом :)
	Ответить | Правка | Наверх | Cообщить модератору

	127. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Вася (??), 15-Авг-26, 13:00
	>> поэтому шифрование на носитель и норм. Но вообще можно просто мусором забить >> разочек. > О ситуации когда форенсик или кто там смог прорубиться в работающую систему > и снять дамп и/или ключи оттуда - мы подумаем немного потом > :) можно придумать тысячу и один сценарий атаки, особенно имея физический доступ и все будут довольно валидные
	Ответить | Правка | Наверх | Cообщить модератору

	137. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (135), 15-Авг-26, 13:29
	> можно придумать тысячу и один сценарий атаки, особенно имея физический доступ и > все будут довольно валидные Ну так чтение уже стертых файлов подразумевает достаточно крутые доступы у атакующего. И есои атакующий все это мог - он и еще много чего интересного сможет делать в системе тогда.
	Ответить | Правка | Наверх | Cообщить модератору

	225. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (223), 15-Авг-26, 21:50
	Зачем им это делать? Я им сам всё заверну куда надо когда придут с правильной бумагой, благо не впервой. А вот вынуть диск из сервера и отдать на утилизацию контрактору не волнуясь что он его до шреддера не донесёт -- priceless.
	Ответить | Правка | К родителю #114 | Наверх | Cообщить модератору

	170. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от NameName (?), 15-Авг-26, 16:36
	это сраказ или десвительное непонимание? что даст экперту гигобайты - точнее весь диск заполненый ошметками бинарных логов? которые еще будут затирать удаленые файлы, и всякое то что может быть нужным?
	Ответить | Правка | К родителю #4 | Наверх | Cообщить модератору

5. "В systemd-journald спустя 6 лет признали проблему избыточной..."	–4 +/–
Сообщение от Аноним (-), 15-Авг-26, 00:48
> В данном случае разработчики systemd продемонстрировали > типичный для корпоративного Open Source подход В данном случае опеннетчики продемонстрировали типичный подход: много критиканить других и мало делать самим. А ваши текстовые логи - это прекрасно. Кроме того момента что даже просто банить околореалтаймно ботов по ним адское мучение. И либо дичайше жрет проц на парсинг гигабайтов - либо требует навороченных энтерпрайзных систем с индексами, и там вопрос амплификации, нагрузки и проч вообще - не раскрыт. А каких-то реально сравнимых решений получить? Что вы, не дождетесь!
Ответить | Правка | Наверх | Cообщить модератору

	9. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+2 +/–
	Сообщение от Аноним (9), 15-Авг-26, 00:53
	Так может лучше задействовать для бана ботов нормальную базу данных, а не эти ошмётки? А текстовые логи оставить только для отладки.
	Ответить | Правка | Наверх | Cообщить модератору

	13. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+1 +/–
	Сообщение от Аноним (16), 15-Авг-26, 01:03
	> Так может лучше задействовать для бана ботов нормальную базу данных, а не эти ошмётки? > А текстовые логи оставить только для отладки. Ваша проблема в том что у вас в итоге только: - Голый зад - и нифига кроме рассказов как все это "не надо". - Невь...й enterprise grade которому для обслуги надо тиму фултайм админов в комплекте. Потому что ваша нормальная база данных - обслуживаемая. И надо - того кто умеет в DBA. Бесплатно работать DBA почему-то не любят. А mid-range и просто возможность забанить надоевших ботиков с своего сервера без огромных напрягов и затрат? В вашей картине мира такое не предусмотрено вообще. А у поттера так можно было. И это причина по которой мир в целом предпочел - его. А вы можете свои базы данных админить, если вам это надо.
	Ответить | Правка | Наверх | Cообщить модератору

	85. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от ыых (?), 15-Авг-26, 08:57
	>  А у поттера так можно было. Драмаквин в треде, развел соплей будто уже это отключили Держи такой же настрой, пригодится когда и твою багу к системде закроют с "not a bug" и коротким каментом про "ты не понимаешь как работает компьютер"
	Ответить | Правка | Наверх | Cообщить модератору

	115. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (-), 15-Авг-26, 11:47
	> Драмаквин в треде, Капитан Очевидность устроивший срыв покровов, не более. > развел соплей будто уже это отключили Нельзя отключить то чего нет. > Держи такой же настрой, пригодится когда и твою багу к системде закроют > с "not a bug" и коротким каментом про "ты не понимаешь как работает компьютер" Мои баги не закроют с этим ризоном. Потому что я понимаю как работает компьютер и могу аргументировать это. И именно поэтому я намного меньше делаю разработчикам мозг. И меньше вру о достигаемых свойствах. Именно поэтому клиенты и выбирают - работу со мной. Добровольно. Зная что системная экспертиза - одно, а загибание пальцев и громкий ор - другое. И именно за счет таких соотношений я могу понять те или иные решения sd. И если что мне пофиг абстрактная амплификация в вакууме. Я оцениваю - параметры системы в целом. Если ssd по замерам протрется не через 100 лет а через всего лишь 50 - да и хрен с ней с амплификацией, его заменят раньше по другим причинам. Вместе с компом.
	Ответить | Правка | Наверх | Cообщить модератору

	205. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+1 +/–
	Сообщение от Аноним (205), 15-Авг-26, 18:43
	> Нельзя отключить то чего нет > У поттера это было Так ты разберись в себе чтоль, что там было или не было > Мои баги не закроют с этим ризоном. Потому что я понимаю как работает компьютер и могу аргументировать это. О, более чем уверен что те, кого реджектали с обоснованиями "не будем делать" - такого же мнения о себе. Просто их уже послали, а тебя (пока) нет
	Ответить | Правка | Наверх | Cообщить модератору

	215. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (-), 15-Авг-26, 20:06
	> Так ты разберись в себе чтоль, что там было или не было У меня вроде бы вполне консистентная точка зрения - мне нравится что появились mid-range варианты которые in between of - педалей с текстовиками где куча проблем и энтерпрайз монстрота с ОБСЛУЖИВАЕМЫМИ БД где надо - извините - DBA в комплекте - и никак иначе. И вообще фултайм штат сотрудников лучше, с хелпдеском и саппортами. Я за то чтобы каждый хост умел немного вон того - без всех депендсей и наворотов энтерпрайз монстров. В этом смысле как оно в sd сделано мне по вкусу. Да и прочие макоси и винды системный логинг как-то так же делают. Но это видимо другое. Чего ради там белым человекам можно а я должен текстовые кривульки с техническими проблемами жрать - я не в курсе. Я вам не помойка для продвижения ваших "офигенных" идей. Особенно когда самые рьяные носители топят за свои вэи из виндов и маков. > О, более чем уверен что те, кого реджектали с обоснованиями "не будем > делать" - такого же мнения о себе. Просто их уже послали, а тебя (пока) нет Меня девы вообще очень редко посылают. Почему-то. Возможно, мы говорим на совместимых протоколах и хотим примерно одного и того же. И да, представляете, вон та проблема - НИКОГДА не вылезала как что-то реально серьезное. Да, я ессно изучаю не просто системные каунитеры а кто сильнее всего их грузит. И sd и его логгер как-то никогда не попадали под внимание как топовые генераторы проблем. Наверное это возможно достичь в каких-то случаях,  но я не в курсе что для этого надо делать. А эстетство ради эстетства я оставлю кому-то другому.
	Ответить | Правка | Наверх | Cообщить модератору

	168. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Ойёёйнаним Плакплакович Причитайкин (?), 15-Авг-26, 16:20
	> Ваша проблема в том что у вас в итоге только По тому, какой вoй поднял, можно судить, что это не "их проблема", а твоя. На ряду с проблемой абсолютной беспомощности в отсутствии васяносоветов из интернетов. Решай проблему - подтягивай компетенции, RTFM, как деды делали, не трать, оплачиваемое хозяином, время на пустой лай. Развёл тут автономию резких, как понос дерзких, пустопорожних пустобрёхов Опеннета. Как ни зайдешь сюда, одно coпливое нытbё - это ему, очередному карапузу, (бесплатно) не сделали, там шнурочки не завязали, тут по-пку не под-тёрли. Это тебе какой-то рыночный самодур в трудовую написал, что ты специалист? Ну так будь добр, соответствуй!
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

	185. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (-), 15-Авг-26, 17:32
	> из интернетов. Решай проблему - подтягивай компетенции, RTFM, как деды делали, Глотнули мы с Максом фанты и читанули крутейший man 3 sd-journdl... ...и тут оказалось что в отличие от дидов логгинг совершенно не обязан е...шить меня граблями по мордаси, а потуги кулхацкера сорвать парсинг - вовсе не обязаны быть именно МОЕЙ проблемой, если логгинг сделать лишь капельку более структурированным :) И мотнуть на 10 сообщений wtf.service назад - вовсе даже и не рокетсайнс парсинга. И не надо кодить заковыристый убер-парсер самому, попутно узнав что юзерье бывает очень креативнно в заполнении полей протокола и парсер может все понять совсем не так как дев себе это изначально представлял. Особенно если это все представить как текст, заранее с неизвестным размером записи лога вообще. > там шнурочки не завязали, тут по-пку не под-тёрли. Сейчас и на тему шнурочков и завязывания - вариаций есть, на все вкусы. Вы думали что мы будем тратить время на завязывание шнурков вечно? Десятки изобретателей решили что таки - не будем. Сделав кучу решений. От банальных липучек до менее банальных модов идеи и даже - автоматическую шнуровку как у Марти Мак Флая если уж на оверинженерию потянуло. За последнее, конечно, дерут. Зато как в back to the future :D > Это тебе какой-то рыночный самодур в трудовую написал, что ты специалист? Ну > так будь добр, соответствуй! Кто и чему соответствует - мы увидим "в поле" :). Все остальное - лирика.
	Ответить | Правка | Наверх | Cообщить модератору

	107. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от User (??), 15-Авг-26, 11:08
	И вот казалось бы, нахрена высовывать ssh голым задом наружу, а потом героически его оборонять костылями? Ну вот есть же хоть tailscale, хоть cloudflare zero-trust, хоть чорт в ступе - но нет, дiды делали и мы будьмо! Как дiды, но не дiды! Локалхост-админы такие локалхост-админы...
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

	120. "В systemd-journald спустя 6 лет признали проблему избыточной..."	–1 +/–
	Сообщение от Аноним (-), 15-Авг-26, 12:25
	> И вот казалось бы, нахрена высовывать ssh голым задом наружу, а потом > героически его оборонять костылями? Чтобы иметь возможность рулить своими системами. С минимумом допущений. Из любой точки планеты. А вы что подумали? И кстати - у меня такое не только на ssh. А на допустим нжинкс, когда всего 1 скан с match на характерное для сканера г - сразу выпиливает сканера. Избавив меня от мегабайта в error log с потугами его сканов далее, ага. Да и подгружать бот теперь будет - только дроп SYN в ядре, а не эвон какой протокольный стек. Так от него вреда радикально меньше, особенно если их таких целая пачка пришла. Или, вот, "undisclosed networking services" для юзеров из РФ которых угораздило там подвиснуть. Да, их периодически пытается щупать сканер. За что все это хозяйство получает автобан. Порой длинный и на всю сканерскую подсеть. Смотря что за паттерн. Нехай им будет неудобно, криво, глючно и дорого в активный пробинг. Добро должно быть с кулаками :) > Ну вот есть же хоть tailscale, хоть cloudflare zero-trust, Вот вы и суйте голову в пасть льва в надежде что он не голодный. А я обойдусь без 3rd-party "благодетелей", этой вашей оверинженерии и проч. Я за более-менее самодостаточные хосты с минимальными допущениями и зависимости. Так лучше работает и меньше неприятных сюрпризов и внеплановых нежданчиков. Люблю когда все просто работает и не делает мозг. > хоть чорт в ступе - но нет, дiды делали и мы будьмо! Не, диды апю journald таки - не дергали. А я в курсе что такое indexed access и key-value DB, и journald - это оно, по большому счету. Я за более-менее автономные и самодостаточные хосты. Выполняющие свои функции независимо от остальных допущений. Хлипкое, ломкое, легко саботируемое окружение - нравится не всем.
	Ответить | Правка | Наверх | Cообщить модератору

	179. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от User (??), 15-Авг-26, 16:56
	Не, ну если на том локалохсте окромя ssh Ничего полезного и нет - и хостов этих не больше трех штук, то можно и так. Подключаешься "откуда-угодно" и настраиваешь, настраиваешь, настраиваешь!!! А если чего полезного делать планируешь - то ну прям типовейшая идея с отделением access plane от control plane и автоматизацией управления группой хостов внутри контура мне нравится существенно больше.
	Ответить | Правка | Наверх | Cообщить модератору

	189. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+1 +/–
	Сообщение от Аноним (-), 15-Авг-26, 17:47
	> Не, ну если на том локалохсте окромя ssh Ничего полезного и нет Да на самом деле - так можно что угодно разруливать. Я и нжинкса так же рюхаю, типовые выводки сканеров улетают в бан на 1-м сообщении, вместо генерации мега бесполезного шаблонного спама в пересчете на бота. Или вон те "сетевые сервисы". Там вообще видимо агрессивные дроны рфской жандармерии пытаются пробить - федот это или не тот. Вон тому - довольно пофиг что рюхать. Префильтр по юниту сильно упрощает парсер, да еще и размер - заранее известен. Так нежданчик скормить - куда сложнее. > - и хостов этих не больше трех штук, то можно и так. Фишка моих хостов - относительная децентрализация. Нет единой точки куда можно эффективно долбануть - и вынести все и сразу, создав какие-то измеримые неудобства. Потому что добро должно быть с кулаками. А всякой мягкотелой энтерпрайзной шушере первым делом и прилетает. Я за относительно самодостаточные хосты. > Подключаешься "откуда-угодно" и настраиваешь, настраиваешь, настраиваешь!!! Скорее разбираюсь с аномалиями - или наруливаю что-то новое. А порой и настраиваю, есть у меня хобби цензоров за нос водить. В основном китайских и рфских для соотв юзерей - но  мне не принципиально каких. А вот автобан их проб - забавно, да :) > А если чего полезного делать планируешь - то ну прям типовейшая идея > с отделением access plane от control plane и автоматизацией управления группой > хостов внутри контура мне нравится существенно больше. Энтерпрайзники в своем репертуаре. При задаче забить гвоздь - пойдут строить фабрику по выпавке металла, чтобы потом из этого сделать машины, и при их помощи сделать молоток... А можно пойти и купить молоток в ближайшем ларьке. Может не такой пафосный, и избыток молотков соседям потом не продашь - но гвоздь будет забит. За куда более обозримое время и с меньшими затратами.
	Ответить | Правка | Наверх | Cообщить модератору

	207. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от User (??), 15-Авг-26, 19:08
	Не, ну если задача была "ботов-с-кулаками" и ничего более полезного делать и не планировалось - то да, можно вот вожжи изолентой-как-у-NASA чинить и рассказывать, что это космокорабль такой, ага. А у нас оно вот как-то так работает последние лет 15. И нет, тебя обманули - ни dba, ни команда админов на фуллтайм для развертывания observability-стека в кубике не требуется. И вне куба тоже (Хоть геморроя и чуть больше). Очнись, Нео! 2006 был 20 лет назад - it с той поры мал-мала вперед ушло.
	Ответить | Правка | Наверх | Cообщить модератору

	227. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (-), 15-Авг-26, 22:08
	> Не, ну если задача была "ботов-с-кулаками" и ничего более полезного делать и > не планировалось - то да, можно вот вожжи изолентой-как-у-NASA чинить и > рассказывать, что это космокорабль такой, ага. Я таки люблю *nix way - ту часть которая "does one thing and does it well". В этом смысле парсинг по мессагам, из итерируемой key-value-like базы, с полями и индексами и несложным префильтром - неплохо вписывается в идею, даже если внутрях это вызов апей. Тем более что выдать это наружу выводом в stdout и сделать юниксвэйный процессинг не проблема. Если ограничения и опасности этого способа - ОК (атакующий потенциально может кормить сервисы в полях их протоколов самым разнообразным хламом, и насколько конкретная программа заботится о безопасности парсеров и логгеров и это удержится vs креативный хацкер - тот еще вопрос). > А у нас оно вот как-то так работает последние лет 15. Я рад за вас. А в чем проблема? До сих пор - можно и на коне покататься, и на ракете полетать. Но не круто - когда меня запрессовывают в 2 крайности, а автомобиль который я на самом деле хотел как mid range - нельзя и баста. Не, ваш космодром мне - дороговат в обслуге! И пафосно тормозить реактивным двиглом перед магазином - избыточно, хоть и зрелищно. А на коне бесплатно - но педально слишком. Авто в самый раз. Даже если и придется порой на сервис кататься и подзаправиться на лугу и у речки не того. А вы почему-то уверены что я должен выбирать из 2 крайностей и никак иначе. > И нет, тебя обманули - ни dba, ни команда админов на фуллтайм > для развертывания observability-стека в кубике не требуется. И вне куба тоже Мне так по жизни никакие ваши кубики ни для чего не требуются. То-есть вообще. Вы предлагаете мне приобрести сотни какого-то нахрен мне не упавшего знания по какой-то нахрен не упавшей мне энтерпрайзятине. При том что я не собираюсь ни пользоваться этим для себя, ни оказывать услуги в этом направлении. Мне вообще такой софт - и энтерпрайзные подходы - не особо импонируют. Ряд идей казавшихся мне удачными, типа VM и контейнеров я упер для себя но - в сильно облегченном и упрощенном виде. Да, космический корабль не так уж плох - но только при условии что удалось обрубить обслуживание и управление до уровня среднего автомобиля. Иначе это для меня уже перебор. > (Хоть геморроя и чуть больше). Очнись, Нео! 2006 был 20 лет > назад - it с той поры мал-мала вперед ушло. Да я так то _некоторые_ технологии энтерпрайзов взял в оборот. Но у меня в целом - свои цели и свой путь. На этом пути лучше не стоять. Я что угодно кроме стандартного наймита под энтерпрайз. Мне не интересны ваши энтерпрайз фиговины. И я не считаю большую часть парадигм чем-то крутым. А что я думаб об accenture и кто ими пользуется я уже доступно обрисовал, имхо.
	Ответить | Правка | Наверх | Cообщить модератору

	131. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (131), 15-Авг-26, 13:20
	А что если хранить логи как базу, через скулайт, например? Она быстрая и маленькая, как раз для этого подходящая имхо. Есть ли такие утилиты логирования уже?
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

	142. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Пыщь (?), 15-Авг-26, 13:49
	Наример, для бомбиана - syslog-ng-mod-sql
	Ответить | Правка | Наверх | Cообщить модератору

	162. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (-), 15-Авг-26, 15:27
	> Наример, для бомбиана - syslog-ng-mod-sql Так, круто, ну и где в результате гайды, хаутушки, примеры? Бенчи? Анализ write amplification, наконец?!
	Ответить | Правка | Наверх | Cообщить модератору

	139. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Джон Титор (ok), 15-Авг-26, 13:44
	Нет, проекты то есть. Публиковать просто как-то не то время. В некоторых райских рассадниках можно получить большие проблемы.
	Ответить | Правка | К родителю #5 | Наверх | Cообщить модератору

10. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+7 +/–
Сообщение от Аноним (175), 15-Авг-26, 00:55
> типичный для корпоративного Open Source подход: критический недочёт в инфраструктурном компоненте игнорировался годами Вся суть архитектуры системды.
Ответить | Правка | Наверх | Cообщить модератору

	17. "В systemd-journald спустя 6 лет признали проблему избыточной..."	–6 +/–
	Сообщение от Аноним (16), 15-Авг-26, 01:17
	>> типичный для корпоративного Open Source подход: критический недочёт в инфраструктурном >> компоненте игнорировался годами > Вся суть архитектуры системды. А альтернативы то какие? Сидеть с голым задом или огроменные энтерпрайзные монстры? Тоже мне дузовные метания мадам грицацуевой.
	Ответить | Правка | Наверх | Cообщить модератору

	23. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+2 +/–
	Сообщение от Аноним (-), 15-Авг-26, 01:30
	А вы со своим тэйком про голые зады по всеё дискуссии растеклись по своей воле или по корпоративной разнарядке? А то что-то тех людей, что системд в дистрибутивы проталкивали, как-то очень быстро перестало быть видно в списках рассылки, что на кое-что намекает.
	Ответить | Правка | Наверх | Cообщить модератору

	37. "В systemd-journald спустя 6 лет признали проблему избыточной..."	–2 +/–
	Сообщение от Аноним (-), 15-Авг-26, 02:24
	> А вы со своим тэйком про голые зады по всеё дискуссии растеклись > по своей воле или по корпоративной разнарядке? Я на лично своих серверах ботов баню за счет функциональности journald. Используя именно его апи indexed access - для конкретных сервисов. Никаких корпоративных разнарядок. И кстати как там тэйки про "настоящие бд" под таким соусом поживают? Или это - другое, не считается, и вообще? > А то что-то тех людей, что системд в дистрибутивы проталкивали, как-то очень > быстро перестало быть видно в списках рассылки, что на кое-что намекает. Да вообще-то основное занятие майнтайнеров и прочих - вовсе не спам в списки рассылки. А так могу простой тэйк закинуть. Допустим мы хотим последние 10 сообщений "вот этого сервиса". Как это через j-d апю делается - да элементарно, ман почитать и через пару часов все будет. А у вас начнутся тэйки что это либо на надо (ибо реверс-парсинг гига текста в таком виде - гемор на всю голову и глюкодром), либо сказки про то что надо "настояющую" БД. И тиму фултайм админов к ней и энтерпрайзной системе логинга. И бюджет на это все. Порсле чего заявы про тейки начинают смотреться особенно интересно.
	Ответить | Правка | Наверх | Cообщить модератору

	43. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (43), 15-Авг-26, 02:45
	>основное занятие майнтайнеров и прочих - вовсе не спам в списки рассылки Вышли из кельи, протолкнули, и назад мейнтэйнить. Благодать. >хотим последние 10 сообщений tail, не?
	Ответить | Правка | Наверх | Cообщить модератору

	60. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+1 +/–
	Сообщение от freehck (ok), 15-Авг-26, 04:44
	>> хотим последние 10 сообщений > tail, не? Ты ему ещё расскажи, что текстовые логи, оказывается, можно ротировать, и поиск сводится к последовательному чтению одного маленького последнего файла =) В то же время journald для той же самой процедуры: - сначала зачитает хэш-таблицу из хедера файла журнала и распарсит её - затем произведёт по ней поиск, найдя все смещения нужных записей далее, ДЛЯ КАЖДОЙ записи: - сделает seek в нужное место heap-а по найденному смещению - вычитает по смещению запись - распарсит запись - и только потом выведет её текстовую часть на экран И если в случае с текстовым логом все эти потоки просто копируются по максимальному размеру буфера, то в случае с journald — оно перекладывается по одной записи за раз, скачет туда-сюда, да ещё и на парсинг структуры каждой зачитанной записи тратит время. =) С верующими адептами Поттеринга — спорить мало смысла. Они ж такие не от высокой экспертизы... =)
	Ответить | Правка | Наверх | Cообщить модератору

	122. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (-), 15-Авг-26, 12:40
	> Вышли из кельи, протолкнули, и назад мейнтэйнить. Благодать. Ну так их активность кроме келий - видна в .service файлах еще. Мне от них что-то такое и надо было. Майнтайнеры должны - пакеты окультуривать. И закрутка гаек условному tor.service более велкам чем спам в рассылке. Просто потому что сетевой сервис с threat level выше среднего - нехило бы и отгородить. На всякий случай. Вместо упования на безгреховность програмеров и что там еще, что видится мне хреновым планом не от мира сего. Для меня это все лучше работает чем сказ о том что мне это не нужно или предложения подраспереться и все это сделайсам. Намного прикольнее когда это майнтайнеры запилили сразу по дефолту своему сервису, а от меня может быть разве что еще дополнения. А не так что фигачьте все с ноля сами или получайте проходной двор на выбор, маэстро. >>хотим последние 10 сообщений > tail, не? Ага, потом хаксор сумевший в инжект 0x0D, 0x0A, 0x00 и проч - очень интересные логи сможет показывать :). И если вы на их основе будете баны лепить... эээ а вот знаете, давать хаксору пострелять из моей Большой Пушки в стороны интересные ему - в мои планы вот вообще совсем не входило.
	Ответить | Правка | К родителю #43 | Наверх | Cообщить модератору

	195. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (195), 15-Авг-26, 18:14
	И как системд защитит от дыры в приложении(подстановка чего-то в логи) и дыры в скрипте(не правильная интерпретация данных в логах)?
	Ответить | Правка | Наверх | Cообщить модератору

	203. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (-), 15-Авг-26, 18:38
	> И как системд защитит от дыры в приложении(подстановка чего-то в логи) и > дыры в скрипте(не правильная интерпретация данных в логах)? Так вот и защитит! Запихнет сервис в отдельный namespace, запретит кучу сисколов через seccomp, вывесит пустой напрочь /home где брать решительно нечего, сделает систему ридонли нахрен от и до, форсанет W^X на процесс, независимо от его умения самому так делать, ... Может это все и не панацея, но это сильно мощнее чем глупые chroot. И используеь фичи Linux которым ...цать лет. А то что их в каких-то допотопных *nix нет мне пофигу вообще совсем. Ну вот моя минимальная болваночка для сервисов: [Unit] Description=WTF service [Service] User=wtf Group=wtf Restart=always RestartSec=10 # Harden it! PrivateTmp=yes PrivateDevices=yes ProtectHome=yes ProtectSystem=strict ProtectControlGroups=yes ProtectKernelTunables=yes ProtectKernelModules=yes MemoryDenyWriteExecute=yes RestrictRealtime=yes RestrictNamespaces=yes LockPersonality=yes ReadOnlyPaths=/run RuntimeDirectory=run NoNewPrivileges=yes Можете показать как вы допустим приватные темпы или девайсы или хомяк сделаете недоступными вон той сетевой байде допустим. А так то с readonly системой, порезаными сисколами, правами и урезанным видом системы - нанести урон "почему-то" становится значительно сложнее. А что до интерпретации - если я получаю от j-d через апю РАЗМЕР СООБЩЕНИЯ ЛОГА - я тогда совершенно не обязан вестсь на 0xD/0xA/0x0 или что там еще за креатив - в body этого лога, которые при рассмотрении мсг лога как текст - на раз будут засчитаны за терминатор текущего сообщения - и значит вон то новая строка, новое сообщение... ой... а это поле протокола такое креативное было и сервис в лог записал "что в проводе было"? Ну вот нате тогда! :)
	Ответить | Правка | Наверх | Cообщить модератору

	45. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (175), 15-Авг-26, 03:17
	> А альтернативы то какие? Спроси у гугла, почему он в хромосе НЕ использует системду.
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

	77. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от arthi747 (ok), 15-Авг-26, 07:36
	Недавно столкнулся с чюдом. Есть такая штука Agent DVR для ip камер, так вот при запуске через systemd она жрет почти в два раза больше чем при запуске из архива.
	Ответить | Правка | Наверх | Cообщить модератору

	232. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (-), 15-Авг-26, 22:48
	>> А альтернативы то какие? > Спроси у гугла, почему он в хромосе НЕ использует системду. Гугл делает много странной фигни. Они видите ли хотели фуксию одно время вообще. Рассказывая вместе с адептами про планы переезда столицы в Нью-Васюки. Потом правда оказалось что не столицы а только сельпо и администрации в виде пары чиновников, и захват мира застрял на паре фоторамок, но говорить не мешало же! Или - кто хочет энтерпрайзно и массово - вот вам андроид вообще! Это - линух который всякие взаимозаменимые винтики и хомы объективно заслуживают. Да, он бастардизирован. Но это то что вы получаете за целование корпоративных ботинок. Об вас взамен начинают вытирать ноги и считать за подставку для ботинок. Какие-то проблемы с этим?!
	Ответить | Правка | К родителю #45 | Наверх | Cообщить модератору

	26. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (26), 15-Авг-26, 01:36
	оверЫнЖЫРнеринг?
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

	74. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от dannyD (?), 15-Авг-26, 06:48
	>>Вся суть архитектуры системды. слепому ясно, но имя им _легион_.
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

	87. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от ыых (?), 15-Авг-26, 09:00
	Вообще в статье неправильно указано - "игнорировался". Это неправильное определение. Для разрабов системды этого бага не было. Их хрупкое эго не могло принять этой проблемы 5 лет, пока вновь русский не пришел и не ткнул носом немцев в их же, кхм, кодовые испражнения
	Ответить | Правка | К родителю #10 | Наверх | Cообщить модератору

18. "В systemd-journald спустя 6 лет признали проблему избыточной..."	–1 +/–
Сообщение от Rev (ok), 15-Авг-26, 01:17
Ждём исправления в нашем любимом Дебиане лет через 6-8.
Ответить | Правка | Наверх | Cообщить модератору

	20. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (20), 15-Авг-26, 01:24
	Хехе, не дождетесь. Там только на профилирование, дебаг и рабочие фиксы уйдёт года полтора-два. Вспоминаем историю #12309.
	Ответить | Правка | Наверх | Cообщить модератору

	25. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (-), 15-Авг-26, 01:33
	А 12309 никуда и не делся. Достаточно попробовать попользоваться машиной с небольшим объёмом озу, жёстким диском и большим количеством устройств на одной линии PCI.
	Ответить | Правка | Наверх | Cообщить модератору

	32. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (20), 15-Авг-26, 01:59
	Вот в этом и суть ;)
	Ответить | Правка | Наверх | Cообщить модератору

	39. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+3 +/–
	Сообщение от Аноним (-), 15-Авг-26, 02:36
	> А 12309 никуда и не делся. Достаточно попробовать попользоваться машиной с небольшим > объёмом озу, жёстким диском и большим количеством устройств на одной линии > PCI. Потом пойти в магазин и обнаружить что сраный китайский мобильник за 50 баксов - работает намного лучше чем весь этот античный кластерфак...
	Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

	84. "В systemd-journald спустя 6 лет признали проблему избыточной..."	–1 +/–
	Сообщение от Аноним (43), 15-Авг-26, 08:53
	Проблема то не решена, а у некоторых конкурентов таких архитектурных просчётов и вовсе не было.
	Ответить | Правка | Наверх | Cообщить модератору

	126. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (-), 15-Авг-26, 12:58
	> Проблема то не решена, Вот конкретная системная трабла - описанная как именно 12309 - таки решена. А то что еще более 9000 похожей фигни в природе может быть - да, но underlyung mechanics и root cause могут быть при этом радикально разные. И вы либо понимаете системы от и до чтобы root cause осознать, или это вообще не ваша епархия - заявлять что это тот же самый баг. Представляете? В интернете бывает такая фигня что вы можете встретить не новичка в девелопе софта - и он устроит вам срыв покровов. > а у некоторых конкурентов таких архитектурных просчётов и вовсе не было. И где все эти офигенные конкуренты? Да и оцениваем мы - свойства системы в целом и общие соотношения. Какой-нибудь QNX например - круто и замечательно, только не у меня. И тут вот коса на камень находит немного. И мои проекты - ловят якорь. А условия харман-кардан - ну не, сами на них agree, если понимаете как с ними вести профитабельный бизнес. А я пешочком постою с этим моим линухом, он видите ли нашару, без NDA, и вообще требований минимум и они простые. Я даже кастомерам сорцы могу дать, мне не жалко. Ибо дофига out of tree патчей мне чисто технически содержать - не того, представляете?! :). Конечно, сорцы только на открытый софт. Всякий кастом - по сильно отдельной договоренности идет уже.
	Ответить | Правка | Наверх | Cообщить модератору

	200. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (195), 15-Авг-26, 18:28
	Ну, если мсье такой проффессионал, может стоит объяснить underlying causes бага, который ведёт себя как 12309 и вызывается как 12309, но не является 12309. Можно не сюда, а сразу в ядерный список рассылки.
	Ответить | Правка | Наверх | Cообщить модератору

	204. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (-), 15-Авг-26, 18:40
	> Ну, если мсье такой проффессионал, может стоит объяснить underlying causes бага, который > ведёт себя как 12309 и вызывается как 12309, но не является > 12309. Можно не сюда, а сразу в ядерный список рассылки. Вот пусть у кого этот баг проявляется - этим и займется? А я на то и это самое что меня работа _моих_ систем устраивает. А когда это не так я и правда прихожу, впрягаюсь, и фикс почему-то занимает немного менее чем 6 лет :). Скорее ближе к 1-2 дня если это нечто не очень крутое.
	Ответить | Правка | Наверх | Cообщить модератору

	218. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (218), 15-Авг-26, 20:28
	https://habr.com/ru/articles/912682/
	Ответить | Правка | Наверх | Cообщить модератору

	236. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (236), 15-Авг-26, 23:01
	> https://habr.com/ru/articles/912682/ Ну так для сведения... 1) У мня на моих нагрузках - я никогда все то не видел. 2) И кстати да, я юзаю MGLRU уже черт знает сколько времени. Как вы уже догадались - я не буду грохать сотни моего времени на воспроизведение проблемы которой у меня даже нет чтобы порадовать какого-то типа с хабры. У него проблемы mem management? Во, киздато - пусть гражданин идет к господам из mm/ и решает это с ними. И да, если вы брякнете про какие-то васян-"моды" ядра в майнлайне вас конечно мигом посичтают за гамно и не будут с вами работать. Таков путь. То-есть вы будете до упора юзать свои васян-моды в результате. А так - жил был баг. Оказавшийся аж в mm/ - и таки долбавший вот именно меня и мои конфиги. Через сутки его почему-то не стало. Может потому что я регресс и словил и бисект выкатил, например? Но я не собираюсь это делать для вообще всех багов на планете - у меня на это "по дефолту" тупо нет ни времени ни желания и есть куча дел интереснее траха с чужими багами которые меня никак не импактят. Если б я был майнтайнером mm/ я бы конечно сказал вам иные слова. Но я не майнтайнер mm/ и вы просто не по адресу.
	Ответить | Правка | Наверх | Cообщить модератору

	136. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (131), 15-Авг-26, 13:27
	В этом и проблема - ну да, на бумаге то оно быстрее, конечно, но к этому мобильнику ты хрен что нормальное подключишь, и хрен какой линукс туда поставишь, а если и поставишь, то ещё нужнт на него софта накатить, возможно придется половину компилять, а еще искать драйверы и прочее. А то железо что, выкидывать?
	Ответить | Правка | К родителю #39 | Наверх | Cообщить модератору

	138. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (-), 15-Авг-26, 13:38
	> В этом и проблема - ну да, на бумаге то оно быстрее, > конечно, но к этому мобильнику ты хрен что нормальное подключишь, и > хрен какой линукс туда поставишь, а если и поставишь, то ещё > нужнт на него софта накатить, возможно придется половину компилять, а еще > искать драйверы и прочее. И тем не менее, примерно такое железо если надо - в виде одноплатника нынче стоит копейки а работает - явно лучше вон того. А если у вас руки совсем из ... - тогда, таки, купите мобильник за 50 баксов а сами займитесь выращиванием рассады. Или что там у вас хорошо получается. > А то железо что, выкидывать? С кучей хлама на одном PCI то? Давно пора ибо это даже не PCI-e еще. Там видите ли by design линки - точка точка. Хотя при остром желании есть и свичи, конечно, но - немного экзотика и в пределах разумного. Так что вон та постановка вопроса - однозначно сообщает нам что дедуле пора на покой, в музей. Приколотите антика на стеночку. Использовать его как что-то практическое в 2026 - когда у китайского тетриса процессор мощнее и обвес без таких проблем - это форменный мазохизм.
	Ответить | Правка | Наверх | Cообщить модератору

21. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+6 +/–
Сообщение от Аноним (21), 15-Авг-26, 01:26
Ну что, теперь системда не будет тормозить на старых пк и одноплатниках?
Ответить | Правка | Наверх | Cообщить модератору

	143. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+1 +/–
	Сообщение от Аноним (143), 15-Авг-26, 13:49
	Ты палку-то не перегибай!
	Ответить | Правка | Наверх | Cообщить модератору

	144. "В systemd-journald спустя 6 лет признали проблему избыточной..."	–1 +/–
	Сообщение от Пыщь (?), 15-Авг-26, 13:51
	Она и на новых тормозит. Только очень быстро.
	Ответить | Правка | К родителю #21 | Наверх | Cообщить модератору

22. "В systemd-journald спустя 6 лет признали проблему избыточной..."	–1 +/–
Сообщение от Аноним (22), 15-Авг-26, 01:29
> для корпоративного Open Source подход цифровая "буржуазная демократия", хехе...
Ответить | Правка | Наверх | Cообщить модератору

	40. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+1 +/–
	Сообщение от Аноним (-), 15-Авг-26, 02:37
	>> для корпоративного Open Source подход > цифровая "буржуазная демократия", хехе... Все демократично: кто работу работает тот и решает что ему надо при этом было :). А вот нытье на форумах и правда мало что решает. Особенно - технические проблемы.
	Ответить | Правка | Наверх | Cообщить модератору

24. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+1 +/–
Сообщение от Аноним (24), 15-Авг-26, 01:30
Я вижу здесь корреляцию со слегка возросшей ценностью SSD, сейчас уже не так просто "купить новый, а старый выкинуть". Людям стало не так легко расставаться с вещами. Надо теперь на браузеры переключаться и постить туда баги, там тоже конь не валялся.
Ответить | Правка | Наверх | Cообщить модератору

	27. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+3 +/–
	Сообщение от Аноним (26), 15-Авг-26, 01:37
	> Надо теперь на браузеры так они хуже всех насилуют диск
	Ответить | Правка | Наверх | Cообщить модератору

	46. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (175), 15-Авг-26, 03:21
	Может, всё-таки лучше всех?
	Ответить | Правка | Наверх | Cообщить модератору

	201. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Мемоним (?), 15-Авг-26, 18:30
	Больше, но хуже.
	Ответить | Правка | Наверх | Cообщить модератору

	140. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Джон Титор (ok), 15-Авг-26, 13:46
	Цена у них растет с проблемами „мировых„ валют. Причину и следствие не путайте
	Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

	191. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от dannyD (?), 15-Авг-26, 18:02
	>>Надо теперь на браузеры переключаться и постить туда баги 1. переносим cache на tmpfs. 2....
	Ответить | Правка | К родителю #24 | Наверх | Cообщить модератору

28. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
Сообщение от Аноним (28), 15-Авг-26, 01:41
> заявили исследовательские претензии Какие?
Ответить | Правка | Наверх | Cообщить модератору

31. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+1 +/–
Сообщение от zionist (ok), 15-Авг-26, 01:51
Примерно так же, уже много лет, многие ждут поддержку SHA256 Git репозиториев в GitHub и в VS Code.
Ответить | Правка | Наверх | Cообщить модератору

35. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
Сообщение от Аноним (35), 15-Авг-26, 02:22
> мейнтейнеры проекта изменили риторику и начали работу над оптимизацией механизмов сброса кэша и структуры хранения индексов journald Ссылка?
Ответить | Правка | Наверх | Cообщить модератору

	42. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+6 +/–
	Сообщение от Аноним (24), 15-Авг-26, 02:43
	> Ссылка? Да я не думаю что будет так строго, скорее всего всем причастным года 2 условно дадут и обяжут таки пофиксить это недоразумение
	Ответить | Правка | Наверх | Cообщить модератору

	47. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+1 +/–
	Сообщение от Аноним (175), 15-Авг-26, 03:23
	> Ссылка? Тут надо просить вышку, а то количество жертв среди SSD слишком велико.
	Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

48. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+5 +/–
Сообщение от Аноним (48), 15-Авг-26, 03:40
Многое говорит про качество подделки systemd, а ведь есть те, которые серьёзно считают, что systemd пример качественного софта. Благо все больше дистрибутивов отказываются от этого переусложненного и некачественного комбайна.
Ответить | Правка | Наверх | Cообщить модератору

	99. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от пгуыыцрщ (?), 15-Авг-26, 10:38
	Всегда подозревал, что systemd - подделка =)
	Ответить | Правка | Наверх | Cообщить модератору

	123. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (123), 15-Авг-26, 12:45
	Считать системд примером качественного софта могут только те, кто никогда не заглядывал в его исходники.
	Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

49. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+1 +/–
Сообщение от ryoken (ok), 15-Авг-26, 03:43
ValdikSS это вроде с лора товарищ? Насколько понимаю, разбирающийся (не то что я). Где-то еще попадались его писания, не упомню.
Ответить | Правка | Наверх | Cообщить модератору

	62. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+2 +/–
	Сообщение от Аноним (62), 15-Авг-26, 05:23
	На хабре
	Ответить | Правка | Наверх | Cообщить модератору

	64. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (64), 15-Авг-26, 05:35
	>"ValdikSS это вроде с лора товарищ" Если с Лора, значит он очень жёстко троллит.
	Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

	65. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+1 +/–
	Сообщение от Аноним (64), 15-Авг-26, 05:36
	>"Где-то еще попадались его писания" Да он такой - вздессущий!
	Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

	91. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+4 +/–
	Сообщение от Xo (?), 15-Авг-26, 09:37
	Легенда. Кодек sbc-xq, обход замедления Ютуба это то чем он занимался.
	Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

	100. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+1 +/–
	Сообщение от пгуыыцрщ (?), 15-Авг-26, 10:39
	это лишь малая, "попсовая" часть, что известна массам.
	Ответить | Правка | Наверх | Cообщить модератору

	96. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+4 +/–
	Сообщение от Пожилая лысая женщина (?), 15-Авг-26, 10:19
	GoodbyeDPI
	Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

	156. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (156), 15-Авг-26, 14:49
	У него для Дебиана есть еще скриптик, который "отключает" синхронизацию после записи каждого файла (Карл!) на диск при установке системы из исошника. Превращая часовую инсталляцию в 15-минутную.
	Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

	157. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (156), 15-Авг-26, 14:51
	А еще вот: https://ru.wikipedia.org/wiki/GoodbyeDPI
	Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

51. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+2 +/–
Сообщение от Аноним (51), 15-Авг-26, 04:06
Единого универсального алгоритма записи действительно не существует, потому что программы решают принципиально разные задачи. Одним важна абсолютная надежность (чтобы данные не пропали при сбое питания), другим — максимальная скорость, третьим — экономия памяти.То, что произошло с systemd-journald — это классический пример того, как инструмент (mmap), созданный для одних целей, применили там, где он категорически противопоказан. Страницы по 4 КБ — да, везде.Это фундаментальное свойство архитектуры современных процессоров (x86_64, ARM) и операционных систем. Память физически нарезана на «страницы» (Pages) по 4 Килобайта, а SSD-накопители внутри себя нарезаны на «блоки» (обычно от 4 КБ до нескольких Мегабайт). Меньше чем одну страницу ОС физически не может выделить или пометить как измененную.А вот mmap используется далеко не везде.mmap (Memory Mapping) — это отличный инструмент, но для очень специфических задач:Для чего он хорош: Для быстрого чтения больших файлов (например, подгрузка текстур в играх или запуск бинарных файлов самой ОС). Вы как бы «накрываете» файл виртуальной памятью и читаете только те кусочки, которые нужны прямо сейчас.Почему он плох для частой записи: В mmap процессом сброса данных на диск полностью управляет операционная система. Программа теряет контроль. Если программа постоянно меняет по 1 байту в разных частях файла, ОС будет сходить с ума, непрерывно помечая 4 КБ страницы как «грязные» и без конца гоняя их на SSD. Разработчики systemd-journald решили объединить текстовые логи в сложную бинарную структуру (чтобы по логам можно было делать быстрый поиск и индексацию) и выбрали для работы с ней mmap.В итоге получился худший архитектурный гибрид: структура данных сложная как у базы данных, но вместо механизмов СУБД (свой кэш, O_DIRECT, WAL) разработчики полностью доверились автоматике mmap. Когда в Linux изменилась логика работы контейнеров (cgroups), автоматика ядра начала бесконечно гонять эти 4 КБ страницы туда-обратно, уничтожая SSD.
Ответить | Правка | Наверх | Cообщить модератору

	61. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+3 +/–
	Сообщение от freehck (ok), 15-Авг-26, 04:59
	Ой, и не говори даже. Самое важное, на что ответа нет: ну вот нахрена логам локалхоста этот долбаный индекс вообще? Для домашней системы и текстовый нормально сойдёт, а для энтерпрайза мы один фиг Elastic или Loki заюзаем. Но это ещё что... Как на счёт такого аргумента: даже если нам вдруг зачем-то нужен индекс... Почему не оставить лог текстовым, как он есть, а индекс — хранить в отдельном файле РЯДОМ с логом? Это, между прочим, сделало бы систему устойчивой к повреждению индекса, и вообще все вопросы с journald сняло бы: все бы Поттерингу только спасибо сказали. В общем, действительно не понятно, зачем journald нужен, и для кого он создавался. Он стоит на наших машинах исключительно потому, что он идёт в составе systemd-комбайна, который нам навязан в качестве промышленного стандарта. И он, как выяснилось, все эти годы портил нам ssd-шки. Спасибо, Леннарт. Почему я не удивлён...
	Ответить | Правка | Наверх | Cообщить модератору

	183. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+1 +/–
	Сообщение от NameName (?), 15-Авг-26, 17:18
	вы как бы вроде правы, и видимо это было основани от раработчиков игнорировать нарекания, но нет не правы. есть проблема, тебе о ней говорят, - прими во внимание. претензия тут только в том- не прошло и 7 лет как. не втехнологии, а в человеческом высокмерном отношении к завялявшим о проблеме.
	Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

	217. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+1 +/–
	Сообщение от Malinovsky (?), 15-Авг-26, 20:20
	Есть. называется Plan9 или современная итерация 9front. Там все есть файл, единый протокол обмена данными и работа с текстом как угодно. И конечно все выглядит как запись в файл или чтение из файла. Очень крутая задумка, только браузера серьезного не хватает, а так можно было бы пободаться даже с линуксом. Страницы по 4Кб или нет, а у меня жесткий диск работает с блоками по 512 байт. Когда нарезка тоньше меньше сухих остатков не содержащих данные. Программа должна уметь объяснять системе что делать. Давно можно использовать Huge Pages, но в работе с файлами она должна указать размер данных. Те самые int или float на пример в языках со статической типизацией, но да, они решили переложить все на mmap, а он тупой, то тут беда. У меня как раз один полудохлый SSD. Спасибо BTRFS и логам, если они тоже постарались. Вывод: в Red Hat и oracle работают одни индюки.
	Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

	234. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (234), 15-Авг-26, 22:55
	Логичный вопрос с задних парт: за каким якодзуном вообще делать структуру логов бинарной, если при ЗАПИСИ этих логов(основная задача) в этом нет ВООБЩЕ НИКАКОЙ необходимости?? Всякие бинарные деревья нужны только при ЧТЕНИИ логов (опциональная функция). Более того - если логи в пределах 10МБ, им вообще никакие вспомогательные структуры не нужны - всё ищется в простом редакторе.
	Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

52. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
Сообщение от Аноним (51), 15-Авг-26, 04:07
Разработчики systemd-journald решили объединить текстовые логи в сложную бинарную структуру (чтобы по логам можно было делать быстрый поиск и индексацию) и выбрали для работы с ней mmap.В итоге получился худший архитектурный гибрид: структура данных сложная как у базы данных, но вместо механизмов СУБД (свой кэш, O_DIRECT, WAL) разработчики полностью доверились автоматике mmap. Когда в Linux изменилась логика работы контейнеров (cgroups), автоматика ядра начала бесконечно гонять эти 4 КБ страницы туда-обратно, уничтожая SSD.
Ответить | Правка | Наверх | Cообщить модератору

	154. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (156), 15-Авг-26, 14:44
	>Разработчики systemd Во всей красе, все правильно. Люблю на это все со стороны смотреть. Даже в срачах не участвую, смысла нет. Просто обожаю наблюдать :)
	Ответить | Правка | Наверх | Cообщить модератору

53. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+1 +/–
Сообщение от iCat (ok), 15-Авг-26, 04:11
Всю дорогу пользуюсь syslog-ng. Хватает "аж за брови". Плюс - вполне себе читаемые логи. Ну как-то странно нагружать логгер ещё и задачами базы данных, криптования и т.п.
Ответить | Правка | Наверх | Cообщить модератору

58. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+8 +/–
Сообщение от Норм (?), 15-Авг-26, 04:40
Системда страшная помойка. Число открытых багов измеряется тысячами. Как и ожидающих пулл реквестов. Но они считают очень важным мержить верификавию возраста. Контроль над репой поделён буквально между одним редхат и одним МС работником.
Ответить | Правка | Наверх | Cообщить модератору

	155. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+1 +/–
	Сообщение от Аноним (156), 15-Авг-26, 14:46
	Все по делу. Но адепты будут с пеной у рта выдумывать отмазки. Это так веселит порой.
	Ответить | Правка | Наверх | Cообщить модератору

	231. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (234), 15-Авг-26, 22:45
	Вопрос: тогда почему до сих пор сустемДы не на помойке истории??? Кто и зачем его тащит в другие дистры (помимо редхат)?
	Ответить | Правка | К родителю #58 | Наверх | Cообщить модератору

59. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+1 +/–
Сообщение от Аноним (59), 15-Авг-26, 04:41
> История тянется с марта 2020 года > разработчики systemd продемонстрировали типичный для корпоративного Open Source подход: критический недочёт в инфраструктурном компоненте игнорировался годами, пока ущерб репутации проекта в сообществе не превысил издержки на его исправление. То есть, знаменитое "сообщество™" за шесть лет вместо исправления проблемы просто продолжало за обе щеки потреблять продукт "корпоративного подхода" - и теперь вы всерьез рассказываете о "репутации проекта" внутри этой группы дармоедов-халявщиков?
Ответить | Правка | Наверх | Cообщить модератору

	90. "В systemd-journald спустя 6 лет признали проблему избыточной..."	–1 +/–
	Сообщение от ыых (?), 15-Авг-26, 09:06
	> То есть, знаменитое "сообщество™" за шесть лет вместо исправления проблемы Какой проблемы? Разрабы системды проблемы не видели. > просто продолжало за обе щеки потреблять продукт "корпоративного подхода" И конечно же ты сейчас внесешь выкладки использования дистрибутивов, включая вариации с замещением журналды на нормальный логгер, в домашнем и корпоративном использовании, за период этих 6 лет
	Ответить | Правка | Наверх | Cообщить модератору

	128. Скрыто модератором	+/–
	Сообщение от Аноним (-), 15-Авг-26, 13:05
	> То есть, знаменитое "сообщество™" за шесть лет вместо исправления проблемы просто > продолжало за обе щеки потреблять продукт "корпоративного подхода" - и теперь > вы всерьез рассказываете о "репутации проекта" внутри этой группы дармоедов-халявщиков? А ты хотел чтобы господа типа freеhck - надувающие щеки в менторском yгapе что и кому "надо" и чего и кому "хватит", да еще из своего мака, еще и кодить умели? :) Не, вот знаете, учитывать таких господ в линухе - и правда никто не будет. И всем похрен что они там поюзают в своем энтерпрайзе, кстати, покуда отдачи с них остальным примерно ноль. Такая ерунда.
	Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

66. "В systemd-journald спустя 6 лет признали проблему избыточной..."	–1 +/–
Сообщение от Аноним (66), 15-Авг-26, 05:51
> разработчики systemd продемонстрировали типичный для корпоративного Open Source подход: критический недочёт в инфраструктурном компоненте игнорировался годами, пока ущерб репутации проекта в сообществе не превысил издержки на его исправление. Изначальный отчет 2000 года закрыли потому, что Поттеринг попросил привести более подробные данные для подтверждения проблемы. Теперь отчет приняли БУКВАЛЬНО потому, что через 6 лет один конкретный человек эти данные наконец-то привел. А новостник тем временем решил напеть о том, что причина на самом деле в каком-то "ущербе репутации в сообществе" да еще и с высоты своего дивана сразу оценил "издержки на его исправление". 🤦 Автор, ты извини, но на то самое пресловутое "сообщество" разработчикам было справедливо наплевать что в 2000 году, что сейчас - разрабы всегда говорят с теми конкретными людьми, кто реально вносит клад и говорит по делу. Поэтому когда в следующий раз захочешь приписать этой группе дармоедов какие-то победы над "корпоративным Open Source" - попробуй постараться сильнее: больше драмы, больше эмоций, больше раздувания слонов из мух, больше ничем не подтвержденных громких заявлений.
Ответить | Правка | Наверх | Cообщить модератору

	67. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (48), 15-Авг-26, 06:05
	Вот пример настоящей нейронки, которая защищает здесь проприетарные и полупроприетарные продукты. Как с галюцинировала про 2000 год, так дальше в тексте и пишет, хотя в следующем предложении правильно пишет про паузу в 6 лет.
	Ответить | Правка | Наверх | Cообщить модератору

	75. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (59), 15-Авг-26, 07:06
	> Вот пример настоящей нейронки, которая защищает здесь проприетарные и полупроприетарные продукты. А где в том сообщении что-то сказано о защите каких-либо продуктов? Там по-моему в защиту здравого смысла и против подачи новостей в стиле бульварных помоев.
	Ответить | Правка | Наверх | Cообщить модератору

	89. "В systemd-journald спустя 6 лет признали проблему избыточной..."	–2 +/–
	Сообщение от Аноним (43), 15-Авг-26, 09:04
	Нейропомои в защиту здравого смысла.
	Ответить | Правка | Наверх | Cообщить модератору

	86. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+1 +/–
	Сообщение от Аноним (86), 15-Авг-26, 08:58
	>разрабы всегда говорят с теми конкретными людьми, кто реально вносит клад и говорит по делу Ни хрена ты разрабов не знаешь. Разрабы говорят *только* с теми людьми, кто их не критикует (они же "высшая каста"!) Попробуй укажи им даже на очевидный их ляп, в ответ получишь море дерьма, не зависимо от того вносишь ты вклад или критикуешь "по делу". Кстати, эта новость прекрасная этому иллюстрация.
	Ответить | Правка | К родителю #66 | Наверх | Cообщить модератору

	93. Скрыто модератором	+/–
	Сообщение от llolik (ok), 15-Авг-26, 09:55
	А влезая в issues тред с ноги, назвав всех дебилами и требуя быстро запилить "не знаю что, но как я сказал" (в общем типичный стиль от "анонимного сообчества") ты ожидаешь какой-то другой реакции, кроме GTFO ? Вобщем-то, сам посмотри тред в issues: типичный стандартный birdie-тупняк, пока в другом тикете ValdikSS, собственно, и не протестировал нормально.
	Ответить | Правка | Наверх | Cообщить модератору

	133. Скрыто модератором	+/–
	Сообщение от Аноним (135), 15-Авг-26, 13:22
	> Вобщем-то, сам посмотри тред в issues: типичный стандартный birdie-тупняк, пока в другом > тикете ValdikSS, собственно, и не протестировал нормально. Ну так системная экспертиза birdie уже всем кто в теме давно очевидна. За что у этого борца с ветряными мельницами репутация - под стать. Впрочем, он хотя-бы честно в нике написал, не создает завышенных ожиданий и отмазка удобная всегда есть.
	Ответить | Правка | Наверх | Cообщить модератору

	147. Скрыто модератором	+/–
	Сообщение от Аноним (147), 15-Авг-26, 14:04
	>> Вобщем-то, сам посмотри тред в issues: типичный стандартный birdie-тупняк, пока в другом >> тикете ValdikSS, собственно, и не протестировал нормально. > Ну так системная экспертиза birdie уже всем кто в теме давно очевидна. > За что у этого борца с ветряными мельницами репутация - под > стать. Впрочем, он хотя-бы честно в нике написал, не создает завышенных > ожиданий и отмазка удобная всегда есть. Где птичка выдал неверные данные?? Ему было лень дальше копать, учитывая, что методология была полная: снимки счётчиков IO для жестокого диска, когда на него не пишет ничего, кроме systemd-journald. ValdikSS получил ровно ту же картину. Как приятно в комментах тихо об$ерать человека, не поняв ничего. Типичный рунет.
	Ответить | Правка | Наверх | Cообщить модератору

	151. Скрыто модератором	+/–
	Сообщение от Аноним (-), 15-Авг-26, 14:21
	> Где птичка выдал неверные данные?? Он ну не то чтобы совсем соврал - просто выдал дофига желтушной отсебятины достойной МК Бульвар по уровню подачи и экспертизы. Зато теории заговоров и отсебятину он смог на 10 из 10. Наверное нику соответствовать пытается. > Ему было лень дальше копать, учитывая, что методология была полная: снимки счётчиков > IO для жестокого диска, когда на него не пишет ничего, кроме > systemd-journald. Зато теории заговора и что там еще за отсебятину с энтерпрайзным опенсорсом ему было не лень... > ValdikSS получил ровно ту же картину. ValdikSS это нормальный и более-менее компетентный кадр, который теории заговора и отсебятину если и толкает то умеренно, понимает о чем говорит и - в отличие от - может обосновать. И не замечен в теориях заговора на тему "корпоративного опенсорца". Ух, представляете, корпы состоят - из людей. А какой-нибудь freehck с своими эластиками топит по интересы корпов куда сильнее чем s-d но это видимо - несчитово. А как по мне так это двойные стандарты. > Как приятно в комментах тихо об$ерать человека, не поняв ничего. > Типичный рунет. Если бы человек не гнал пургу с умным видом периодически, устраивая отсебятину с теориями заговора - отношение было бы иным. Заметьте - к ValdikSS отношение совсем иное. Потому что тот обычно ПОНИМАЕТ о чем говорит, а не разводит теории заговора. Другие соотношения.
	Ответить | Правка | Наверх | Cообщить модератору

	186. Скрыто модератором	+/–
	Сообщение от Аноним (147), 15-Авг-26, 17:37
	>  просто выдал дофига желтушной отсебятины достойной МК Бульвар по уровню подачи и экспертизы Примеры будут? Или будем дальше PIздеть? Что в тикете "отсебятина"? Не надо про дальнейшие комменты (где разрабы упёрлись), я про сам тикет. > Зато теории заговора и что там еще за отсебятину с энтерпрайзным опенсорсом ему было не лень... Какие теории, если systemd = IBM/RedHat, и PR от 3х лиц они принимают крайне неохотно? > ValdikSS это нормальный и более-менее компетентный кадр Ticket второй не его. У него просто подгорело, и он решил проверить факты. Оказалось, что birdie - прав. > - в отличие от - может обосновать. Счётчики IO от ядра - это не "обоснование"? Вы уже начали нести и не расплёскивать. >  А как по мне так это двойные стандарты. Всё ваше сообщение - да, несомненно. Оригинальный ticket содержал всю нужную информацию. За дело взялись ровно после того, как это взорвалось на Hacker News, и плевать было разрабам на какой-то коммент какого-то русского. Тьфу ты. Вы даже не в теме, б*ь. Вы даже прочитать по ссылке ничего не могли. Уровень об$ирания 1000й, уровень понимания темы - ниже плинтуса. > Если бы человек не гнал пургу с умным видом периодически, устраивая отсебятину с теориями заговора Примеры будут? Хоть один??
	Ответить | Правка | Наверх | Cообщить модератору

	192. Скрыто модератором	+/–
	Сообщение от Аноним (-), 15-Авг-26, 18:02
	> Примеры будут? Или будем дальше PIздеть? Да вот же - прямо новость. С слезными сказками про корпоративный опенсорс, yada-yada. 1) А почему Поттеринг на Linux Plumbers смог при этом услышать нужды эмбедеров и запилить что просили? 2) И почему тушки которые на виду - вот именно уровня васян - в sd комитнуть могут? Наблюдаемое вокруг очень радикально отличается от опеннетовых сказок. > Что в тикете "отсебятина"? Я про эту новость а не тикет. Тут какие-то сказы о заговоре энтерпрайзного опенсорца. Особенно круто в пару смотрятся всякие freehck с ластиками и прочие user с их оверинженерией. Вот уж воистину все познается в сравнении, на их фоне sd journal это мелкая аккуратная фигня, почти zero-deps :) > Какие теории, если systemd = IBM/RedHat, и PR от 3х лиц они > принимают крайне неохотно? Я видел комиты от условных васянов которые на виду. Так что держите меня в курсе. > Ticket второй не его. У него просто подгорело, и он решил проверить > факты. Оказалось, что birdie - прав. Он в отличие от - может нормально описать. А birdie - вот именно что только чирикать способен. Поэтому и эффективность его репортов - под стать. Спорим что если бы пришел я - эффект был бы другим? Но меня вон то вообще на типовых кейсах моих систем - не парит тупо. Т.е. прогнозируемые времена жизни ssd обычно десятки лет и основные writer уж точно не системы логгинга. > Счётчики IO от ядра - это не "обоснование"? Вы уже начали нести > и не расплёскивать. Обоснование - это почему то или иное значение является проблемой. Кончина ssd что через 100 лет чот через аж 50 - "notabug" для лично меня. Максимум эстетика. Кто его там полвека будет гонять такой вообще? > За дело взялись ровно после того, как это взорвалось на Hacker > News, и плевать было разрабам на какой-то коммент какого-то русского. Тьфу > ты. Вы даже не в теме, б*ь. Я вижу что вот именно тут - разведена какая-то отсебятина про какой-то энтерпрайзный опенсорс. И поэтому вместо новости - какой-то МК Бульвар получился. Типично для birdie.
	Ответить | Правка | Наверх | Cообщить модератору

	202. Скрыто модератором	+/–
	Сообщение от Admino (ok), 15-Авг-26, 18:33
	> Где птичка выдал неверные данные?? Слушь, но он на полном серьёзе считал количество строчек, которые записываются в лог.
	Ответить | Правка | К родителю #147 | Наверх | Cообщить модератору

	220. Скрыто модератором	+/–
	Сообщение от Аноним (147), 15-Авг-26, 21:18
	Данные valdikss точно повторяют данные birdie 6 летней давности. Баг начал фиксить разраб systemd после того, как тему раздули на hacker news. ValdikSS ровно ничего, кроме коммента, не сделал. Что тут все несут??
	Ответить | Правка | К родителю #93 | Наверх | Cообщить модератору

	182. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (175), 15-Авг-26, 17:13
	> отчет 2000 года нейро-slop, не пались. 2026 - 6 = 2000 год?!
	Ответить | Правка | К родителю #66 | Наверх | Cообщить модератору

	188. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (147), 15-Авг-26, 17:47
	>> отчет 2000 года > нейро-slop, не пались. 2026 - 6 = 2000 год?! В апреле 2020 не было даже ChatGPT 3.0. Что вы несёте?
	Ответить | Правка | Наверх | Cообщить модератору

	216. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (205), 15-Авг-26, 20:07
	Эх, еще бы уметь собственным интеллектом пользоваться не только ради заучивания дат от интеллекта искусственного Давай я тебе помогу: тут речь не про гопоту которая когда-то вышла, а про то, что кто-то не смог сформулировать мысли и пошел просить гопоту их написать. А та поймала галюнов и выдумала 2000 год создания тикета. Естественно, вопрощающий даже не вычитывал, а просто скопировал текст
	Ответить | Правка | Наверх | Cообщить модератору

70. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
Сообщение от Аноним (70), 15-Авг-26, 06:28
Ждём того же, но уже у proxmox. У них тоже база данных своя активно пишет на диск и природа проблемы схожая.
Ответить | Правка | Наверх | Cообщить модератору

72. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
Сообщение от Аноним (72), 15-Авг-26, 06:34
Там Федора оказывается.Просто увидел знакомые буквы в аптайм.
Ответить | Правка | Наверх | Cообщить модератору

82. "В systemd-journald спустя 6 лет признали проблему избыточной..."	–2 +/–
Сообщение от Аноним (82), 15-Авг-26, 08:32
А зачем вообще простому смертному юзеру логи?
Ответить | Правка | Наверх | Cообщить модератору

	165. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Халявщик не корпораст (?), 15-Авг-26, 15:44
	Ну так логи(не все конечно) как и всякие кейэрдипи, самбы, эсэсэйчи и другие типа зависимости без который у того юзера не будет ни файлового менеджера нормально работающего, да и ваще вся округа завалится и всё - юзер будет в консоле работать типа мышкой, смотреть фотки с видосиками и в инет выходить, патамушта это вот всё прибито гвоздями и без этого типа никак. Это вот всё нужно для того юзера на другом конце провода, который типа никуда не лезет и ничего не знает, и не помнит тоже ничего от слова совсем... Любой дистр заклёпан под это всё и давно уже, либо сам пили себе дистр и юзай, но в зависимостях всё равно этот шлак для домашнего компа будет притянут за хвост... :)
	Ответить | Правка | Наверх | Cообщить модератору

83. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+2 +/–
Сообщение от Аноним (83), 15-Авг-26, 08:41
Спасибо ValdikSS! Мегакрутой Специалист!
Ответить | Правка | Наверх | Cообщить модератору

92. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+2 +/–
Сообщение от Квас (?), 15-Авг-26, 09:44
> ValdikSS What a legend
Ответить | Правка | Наверх | Cообщить модератору

98. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
Сообщение от Аноним (98), 15-Авг-26, 10:25
Как узнают на hackernews и ycombinator так сразу отваливается вся идеалогия. Ведь бабки можно потерять, стартапов да корпы узнаю что шиза важнее производительности
Ответить | Правка | Наверх | Cообщить модератору

109. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+1 +/–
Сообщение от skkriptkidds (?), 15-Авг-26, 11:16
Все что нужно знать об этой поделке и ее разрабах. Грустно.. в начале идеи были правильные.
Ответить | Правка | Наверх | Cообщить модератору

111. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+1 +/–
Сообщение от Аноним (111), 15-Авг-26, 11:37
Ведение бинарных логов под Linux - одна из самых, самых идиотских идей, какие только приходили в голову. Польностью ломает концепцию Unix. Одно дело, если ты делаешь логирование так, чтобы логи можно было, допустим, сразу запихивать в базу данных. Желательно - по сети. При этом продолжая писать (менее подробные) логи в обычные текстовые файлы. Другое дело - когда вариантов просто нет, по умолчанию "пишем бинарные логи". Да блин! Ещё и формат этих бинарных логов постоянно меняют и дорабатывают. Вот, у меня на объекте крэшнулся линукс-сервер. Прямого доступа к нему даже теоретически нет. Логи скопировали и привезли на флэшке. И теперь, вместо того чтобы открыть и проанализировать их на любой машине (да хоть под виндой, да хоть со смартфона) мне надо искать или специально развёртывать ту же версию операционной системы. Насколько было проще, пока те же логи были в тупом текстовом формате. Ага, и время от времени ротировались и сжимались gzipом. --------------------------------------- Логирование должно быть простым! Очень простым. Реально простым. Зато чтобы всегда работало.
Ответить | Правка | Наверх | Cообщить модератору

	161. "В systemd-journald спустя 6 лет признали проблему избыточной..."	–1 +/–
	Сообщение от Аноним (161), 15-Авг-26, 15:14
	> --------------------------------------- > Логирование должно быть простым! Очень простым. Реально простым. > Зато чтобы всегда работало. Еще не хватало чтобы юзеры винды нем тут рассказывали какие логи должны быть. Сидючи то на своих бинарных логах в винде, и видимо - не жмет.
	Ответить | Правка | Наверх | Cообщить модератору

116. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+1 +/–
Сообщение от Аноним (116), 15-Авг-26, 11:51
Пишем в journald.conf: [Journal] Storage=none ForwardToSyslog=yes Ставим rsyslog и наслаждаемся тем, как оно было раньше.
Ответить | Правка | Наверх | Cообщить модератору

	130. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (135), 15-Авг-26, 13:20
	> Пишем в journald.conf: Можно вообще systemctl mask journald.service и развесте свой сислог если оно вам надо. Вот только не понятно зачем саботировать полезные фичи системы. Но если очень хочется, можно назло бабушке отморозить уши, отстрелить выступающие части тела, и вообще...
	Ответить | Правка | Наверх | Cообщить модератору

117. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+1 +/–
Сообщение от Аноним (117), 15-Авг-26, 11:51
Если при установке врубил `Storage=volatile` для `journald`, меня эта проблема не должна касаться? Жалко SSD с системой почем зря гонять, специально брал дорогой NVMe (еще до скачка цен дорогой) под систему, небольшой по объему но с ОЧЕНЬ большой скоростью чтения/записи. А домашний каталог на втором SATA SSD, который сильно попроще но больше но объему и дешевле.
Ответить | Правка | Наверх | Cообщить модератору

	209. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (147), 15-Авг-26, 19:33
	Storage=volatile - хранить все в ОЗУ, винт не трогать.
	Ответить | Правка | Наверх | Cообщить модератору

	222. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (222), 15-Авг-26, 21:34
	А если рама не резиновая?
	Ответить | Правка | Наверх | Cообщить модератору

	244. Скрыто модератором	+/–
	Сообщение от Аноним (-), 16-Авг-26, 00:47
	> А если рама не резиновая? Выше пример как залимитировать размер системного журнала до N мегабайтов...
	Ответить | Правка | Наверх | Cообщить модератору

119. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
Сообщение от hisi (?), 15-Авг-26, 11:59
redhat  (fedora)  правильно всё  сделали   - пишут в /run/systemd/journal  по минимому остальное rsyslog
Ответить | Правка | Наверх | Cообщить модератору

	125. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (125), 15-Авг-26, 12:55
	rsyslog читает из фалов journald. Так что пишет там как journald+rsyslog (в плане операций записи, а не объема)
	Ответить | Правка | Наверх | Cообщить модератору

146. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
Сообщение от Аноним (146), 15-Авг-26, 13:59
Бесят проги, которые используют накопители как помойку. Многие сразу создают .log файл при запуске, даже когда нет ошибок (Xorg.0.log)
Ответить | Правка | Наверх | Cообщить модератору

148. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
Сообщение от Аноним (21), 15-Авг-26, 14:04
Пора переписывать systemd по частям. Начнём с логгера.
Ответить | Правка | Наверх | Cообщить модератору

166. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
Сообщение от Аноним (166), 15-Авг-26, 16:12
Они по сути ссылались ан абстрактное понимание уровня BTRFS для которой нормально убивать твердотельные накопители адской записью. Надо было читать что все происходит на XFS - самой стабильной файловой системе и что там такого не должно было быть в принципе. Тугодумы редхатовские просто ужас какие. Они и ненужнодэ непонятно нафига всем впарили. Тоже наверняка объяснить сами не смогут чего это разработчик этого поделия к мелкомягким ушел. Такой вот он развиватель линукса.
Ответить | Правка | Наверх | Cообщить модератору

	198. Скрыто модератором	+/–
	Сообщение от Аноним (198), 15-Авг-26, 18:21
	Так это, за красных или за белых?
	Ответить | Правка | Наверх | Cообщить модератору

	210. Скрыто модератором	–1 +/–
	Сообщение от Malinovsky (?), 15-Авг-26, 19:52
	> Так это, за красных или за белых? Лично я за белых. Красные мою семью ограбили, депортировали в Сибирь за то что было свое хозяйство и чуть всех не поубивали. Жаль белые не перебили всех кто считал нормальным на своих нападать грабить, мучить и убивать людей, включая детей.
	Ответить | Правка | Наверх | Cообщить модератору

172. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
Сообщение от Аноним (172), 15-Авг-26, 16:38
Уважаю ValdikSS, настоящий хакер!
Ответить | Правка | Наверх | Cообщить модератору

196. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
Сообщение от Аноним (196), 15-Авг-26, 18:15
Not a bug!
Ответить | Правка | Наверх | Cообщить модератору

199. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
Сообщение от Ненищ Безокр (?), 15-Авг-26, 18:26
С одной стороны, вот сейчас все ревнители "ресурса" напряглись. С другой стороны, у этих ревнителей не должно быть системы Д по-умолчанию. А с глобальной стороны - линукс снова портит железо. Ранее он портил HDD багом с парковкой, теперь портит SSD. П - преемственность. Но ничего удивительного.
Ответить | Правка | Наверх | Cообщить модератору

211. Скрыто модератором	+/–
Сообщение от Аноним (211), 15-Авг-26, 19:55
systemd достал конкретно. systemd - это Зло. Надо обратно переходить на SysV init.
Ответить | Правка | Наверх | Cообщить модератору

214. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+1 +/–
Сообщение от Ilya Indigo (ok), 15-Авг-26, 20:04
Уже более 15 лет отключаю journald и использую rsyslog!
Ответить | Правка | Наверх | Cообщить модератору

	240. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (175), 15-Авг-26, 23:44
	Никогда не использовал системду вообще.
	Ответить | Правка | Наверх | Cообщить модератору

221. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+1 +/–
Сообщение от Аноним (222), 15-Авг-26, 21:32
А  ВКЛЮЧЕННОЕ ПО ДЕФОЛТУ ДЕТАЛЬНОЕ ЛОГИРОВАНИЕ всего и вся - оно для чего, разрабы не желают пояснить?
Ответить | Правка | Наверх | Cообщить модератору

	245. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (-), 16-Авг-26, 00:50
	> А  ВКЛЮЧЕННОЕ ПО ДЕФОЛТУ ДЕТАЛЬНОЕ ЛОГИРОВАНИЕ всего и вся - оно > для чего, разрабы не желают пояснить? Давайте я за него поясню. В этом мире очень мало вещей расстраивают меня больше чем когда я допустим запилил новый сервис в систему. Тестовый пинок. Вроде все ок. Ребут и .. тишина. Просто тишина. Гляцкий sysv, я так люблю это чувство. Больше я люблю только чувство что хорошо что все это теперь - не у меня :)
	Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема