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

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

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

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

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

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

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

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

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

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

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

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

	314. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от _ (??), 17-Авг-26, 17:17
	Ну единственное разумное что приходит на ум - он не про локалхост, а про агрегатор, ну типо  logstash какой-нить... Но оно для траблшута паники на given loalhost помогаетЪ ве-е-е-е-есьма частично :( О5-же - там где логсташи крутят я уж и забыл когда панику ведра _траблшутили_ ... kill the instance; create the instance; ansible new_node_initpack.F22A47DZ  ну или как там оно у вас :)
	Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

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

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

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

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

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

	318. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от _ (??), 17-Авг-26, 17:34
	Бинго! А как ты думаешь логи появились? :)
	Ответить | Правка | К родителю #260 | Наверх | 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ообщить модератору

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

	280. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от windows10 (ok), 16-Авг-26, 14:57
	> Проблема всех этих eMMC, NAND, и даже MicroSD, в том что они > они крашатся и быстро теряют ресурс, при многократном записывании кучи мелких > файлов, таких как логов. > Тоесть от постоянной перезаписи мелких файлов, ресурс, накопителя, улетает. Вот именно. Но если с нормальным инитом, этот "улет" будет через 5 лет работы 24\7, то с systemГ - через 2 года. Между 24 месяцами и 60 месяцами разница все же большая.
	Ответить | Правка | Наверх | Cообщить модератору

	342. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (-), 19-Авг-26, 13:15
	> Вот именно. > Но если с нормальным инитом, этот "улет" будет через 5 лет работы > 24\7, то с systemГ - через 2 года. Между 24 месяцами > и 60 месяцами разница все же большая. Вот и юзайте свою винду - там все равно за вас майкрософт решит как вам ЗБС и вообще не спросит. А линуксоидам слушать человека с ником рекламирующим винду - как минимум очень странно.
	Ответить | Правка | Наверх | Cообщить модератору

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

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

	316. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+1 +/–
	Сообщение от _ (??), 17-Авг-26, 17:27
	Ага, помечтай... :( In real world: Нет Linux, есть проблемы с другой озЪю. Choose the pill, Leo!(C)
	Ответить | Правка | Наверх | 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 +/–
	Сообщение от Аноним (1), 15-Авг-26, 16:57
	Можно и так, но этот режим накладывает некоторые неприятные ограничения.
	Ответить | Правка | Наверх | Cообщить модератору

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

	194. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+1 +/–
	Сообщение от Аноним (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ообщить модератору

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

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

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

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

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

	6. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+18 +/–
	Сообщение от Аноним (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 лет признали проблему избыточной..."	–1 +/–
	Сообщение от Аноним (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ообщить модератору

	310. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от freehck (ok), 17-Авг-26, 14:20
	> если у меня был 1 сервер а стало 2 - это увеличение нагрузки вдвое Смешно. =) Он даже не понимает, что данный пассаж мгновенно обнуляет его мнение как таковое: человек не умеет масштабироваться, для него второй сервер = вдвое больше работы, подумать только. А я-то думал, что ничего смешнее, чем байки про защиту от ddos-атак через бан-скрипт, анализирующий логи, уже не будет. Как наивно с моей стороны! =) upd: а, погодите-ка, это один и тот же аноним... my bad! =)
	Ответить | Правка | Наверх | Cообщить модератору

	343. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (-), 19-Авг-26, 13:30
	> А я-то думал, что ничего смешнее, чем байки про защиту от ddos-атак через бан-скрипт, Вообще-то наша ключевая разница - в том что я системщик. И умею программировать. И даже не только ваши вcp@тые скриптики - но и high-performance тулсы. Вполне способные отбить app-level ddos интенсивности когда текстовые логи отрастали на примерно 5 Гб в день и даже просто фронт nginx заметно грузил проц. Мне и стало интересно как в рамках локалхоста этих злыдней забанить - БЕЗ ващих е...чей оверинженерии. Дешево и сердито, быстро и компактно. То что вам не дано. > анализирующий логи, уже не будет. Как наивно с моей стороны! =) А так - тулсы так то довольно годные получились. Ещи и в tox спамить мне умеют, так что алерты для СЕБЯ у меня сделаны в квази-распределенном виде. Без больших кораблей, которым можно выписать большую торпеду. Just because I can :). > upd: а, погодите-ка, это один и тот же аноним... my bad! =) Квалификация и тут лезет из всех щелей.
	Ответить | Правка | К родителю #150 | Наверх | Cообщить модератору

	365. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от freehck (ok), 19-Авг-26, 17:39
	>> А я-то думал, что ничего смешнее, чем байки про защиту от ddos-атак через бан-скрипт, анализирующий логи, уже не будет. > Вообще-то наша ключевая разница - в том что я системщик. Ключевая разница между нами в том, что у меня экспертиза в отражении реальных ddos-атак — есть. =)
	Ответить | Правка | Наверх | Cообщить модератору

	366. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (-), 19-Авг-26, 18:16
	Насколько я вижу - у вас есть опыт в 1) Загибании пальцев. 2) Пафосе. 3) Абузе полномочий и демо своей безблагодатности. 4) При полном отсутствии каких либо лично ваших достижений в чем либо. У вас вранье начинается прямо с ника. Вы и не free, тем более с заявами про цензуру, и не hck - а печальный корпоративный винтик и потребитель. Без каких либо собственных проектов о которых стоило бы говорить вообще.
	Ответить | Правка | К родителю #343 | Наверх | Cообщить модератору

	344. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (-), 19-Авг-26, 14:05
	> Затем, что я не инициирую дискуссии с анонимом. Мне на вас плевать. Полфорума за мной гнались чтобы рассказать как на меня плевать? >> ИМХО, в опенсорсе не место вашим менторским монологам. > А есть варианты получше? Вы можете просто отправить двойные стандарты и вранье туда где им самое место. Когда некто сидит под маком и поливает технологии, которые на маке - и launchd, и какие еще логи, и что там, а для linux почему-то стандарты другие - не комильфо. Что я скажу? Самое крутое что в Linux можно быть первым сортом. Не хуже виндов и мака! Юзая примерно те же продвинутые технологии, включая норм апи, без сдачи пропертарщикам в рабство, во. Я не обязан ограничивать себя вашими педалями! И выбор оказывается - шире чем текстовики с кучей проблем vs мега-энтерпрайз тулсы! > Ты ж на серьёзных щах писал, что борешься с ddos-ами, натравливая скрипт Я на серьезных щщах писал что написал себе high-performance автобаннер. Юзающий апю journald. Как нативный код - в таком виде может до кучи отбить небольшой app layer ddos. Мне просто интересно было зарубиться с стайкой ботов и выбор типа вон того - не возбуждал. Почему-то. >> В этом мире слишком много знаний - поэтому я изучаю только ценные и реюзабельные. > Ну-ну. А когда вам нужно прод для клиента построить — вы как это умудряетесь делать, У меня специфичные проды и клиенты. И кроме всего прочего, если клиент удумает мне диктовать стеки технологий и проч - он будет строить прод сам. Таков путь. > не обладая даже базовыми знаниями о том, как устроен пакетник в вашем дистрибутиве? Видите ли, я умею оперировать в более чем 1 роли. Да, если я выкатываю complete solution - я и правда знаю азы предпочинаемого дистро и его пакетника. А если я хреначу в режиме программиста, оформляя "продукт" - мне микродетали каждого дистро не в тему. Знать о rpm-based я их spec я не хочу примерно  ничего: для решений выкатываемых мной и себя лично - я все это не юзаю. Пусть сами разбираются. Аналогично всякие арчи и что там еще за генты. А я положу .service файло - и вся любовь. Мне так проще. > Эти знания не ценные и не нужные, да? =) Я ничего не делаю с rpm-based и изучать какие там еще spec файлы у них мне не с руки. Аналогично для arch-based, gentoo, или whatever... sd сильно урезает "матрицу" знаний и допущений. А у кого системды нет - ему и приблуда юзавшая sd api ни к чему, например :D
	Ответить | Правка | К родителю #150 | Наверх | 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 лет признали проблему избыточной..."	+1 +/–
	Сообщение от вымя (?), 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 лет признали проблему избыточной..."	+/–
	Сообщение от вымя (?), 15-Авг-26, 06:21
	...которые в логе вообще не отсвечивают. Вот где в журнале написано про запуск dnf-makecache.timer? А он запустился, вон, свежие следы в /var/cache лежат! «Неудобно работать с логами? Просто выкиньте их!» Гениально. В таймерах этих ещё и stdout/stderr без костылей не попадает ни в хвалёный journald, ни на почту. Свои-то файлы мне, может, и не жалко подпереть, но вот следить за миллионом дистрибутивных файлов для того, чтобы обставлять их override-ами, желания нет никакого. Но вы, конечно, не прекращайте восхищаться гением Лёни, подарившему админам локалхостов многословный ароматизатор crontab, не идентичный натуральному.
	Ответить | Правка | Наверх | Cообщить модератору

	110. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+1 +/–
	Сообщение от Аноним (-), 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ообщить модератору

	282. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от freehck (ok), 16-Авг-26, 16:19
	> Если вы не даете анонимам отвечать, то зачем инициируете дискуссии с анонимом? Затем, что я не инициирую дискуссии с анонимом. Мне на вас плевать. Мне не плевать на людей, которых вы пытаетесь ввести в заблуждение. > ИМХО, в опенсорсе не место вашим менторским монологам. А есть варианты получше? Ты ж на серьёзных щах писал, что борешься с ddos-ами, натравливая скрипт на логи nginx-а. Тут, как ни ответь, получится что-то менторское. =) > В этом мире слишком много знаний - поэтому я изучаю только ценные и реюзабельные. Ну-ну. А когда вам нужно прод для клиента построить — вы как это умудряетесь делать, не обладая даже базовыми знаниями о том, как устроен пакетник в вашем дистрибутиве? Эти знания не ценные и не нужные, да? =)
	Ответить | Правка | Наверх | 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. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (-), 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ообщить модератору

	249. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (249), 16-Авг-26, 01:09
	> Unit - не синоним активного запущенного процесса(-ов). Про какой-нибудь RemainsAfterExit > вы видимо тоже не слышали. Т.е. юнит может считаться запущенным - > при 0 активных процессах. зачем так ломать перезагрузку? это ысегда лотерея с mount юнитами, чего они ждут так долго? причем во всех дистрибутивах где системд, рач, центос, дебиан, уже примерно 10 лет
	Ответить | Правка | Наверх | Cообщить модератору

	345. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (-), 19-Авг-26, 14:17
	> зачем так ломать перезагрузку? это ысегда лотерея с mount юнитами, чего они > ждут так долго? причем во всех дистрибутивах где системд, рач, центос, > дебиан, уже примерно 10 лет О чем все это? У меня системы, очевидно, загружаются. И выключаются. Иначе я бы даже просто вот тут откоментить бы облажался. Потому что вот это - виртуалка с клоном моего десктопа, с системд. На хосте, тоже с системд. И конект идет через несколько систем, часть из которых тоже - с системд. Соответственно - в целом все просто работает. А то что в каких-то конкретных случаях возможны отклонения - так в sysv они и еще более мерзкие возможны. Портировал я как-то sysv скрипты с RPM -> DEB, при тестовом пинке все ок. А ребутаем сервер - и тишина. Угадайте-ка что там отвалилось, где и почему. Не, логинг какого там еще stdout и прочих кодов ошибок по дефолту? "Но вы можете накодить это сами!". Ух да, на каждый такой прецедент буду в каждую скрипто-вермишель сам такие макароны добавлять. А оно мне такое надо, когда можно - вон то? Где это все - out of the box? Я себе не враг и убивать мое время на проблемы которых вообще быть не должно не буду, и если какой-то вэй требует такое - это плохой вэй, мне с ним не по пути в этом аспекте.
	Ответить | Правка | Наверх | Cообщить модератору

	108. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+2 +/–
	Сообщение от Аноним (-), 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 лет признали проблему избыточной..."	+1 +/–
	Сообщение от Аноним (-), 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ообщить модератору

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

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

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

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

	284. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от freehck (ok), 16-Авг-26, 16:50
	> Ну и скачи потом по всем хостам в поисках "а на какой же ноде этот вот запрос отработал?!" Мужик, ну о чём ты вообще? Очевидно же, что у них никогда не было столько хостов, чтобы "скакать по всем хостам" было бы проблемой. Более того, они и задачей обеспечения отказоустойчивости никогда не занимались, и потому вопроса "на какой ноде этот запрос отработал" — у них тоже нет: откуда бы ему взяться, если все сервисы в единственном экземпляре и жёстко к нодам прибиты? =)
	Ответить | Правка | К родителю #206 | Наверх | Cообщить модератору

	289. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от User (??), 16-Авг-26, 18:44
	>> Ну и скачи потом по всем хостам в поисках "а на какой же ноде этот вот запрос отработал?!" > Мужик, ну о чём ты вообще? Очевидно же, что у них никогда > не было столько хостов, чтобы "скакать по всем хостам" было бы > проблемой. Более того, они и задачей обеспечения отказоустойчивости никогда не занимались, > и потому вопроса "на какой ноде этот запрос отработал" — у > них тоже нет: откуда бы ему взяться, если все сервисы в > единственном экземпляре и жёстко к нодам прибиты? =) Ну, я вот своими глазами видел мужика, который в 21 веке на каменных ножах деньги зарабатывал - сидит на улочке иджун, камушком-по-камушку тюк-тюк - туристы довольны. Тоже бизнес, рыночная ниша, не удивлюсь даже если и вполне себе прибыльная. Но он - в отличие от - это все _молча_ делал, а не доказывал всем вокруг с пеной у рта, что вот оно - новое-прекрасное-будующее(будующего), и не надо ему этих наших ТЛЕТВОРНЫХ ВЕЯНИЙ, что вот оно освоил НОВУЮ ТЕХНОЛОГИЮ и по черный камень сейчас стучит не другой камень, а вот - железкой, такой же как у самого главного белого бваны, а все остальные просто НИАСИЛИЛИ...
	Ответить | Правка | Наверх | Cообщить модератору

	301. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от freehck (ok), 17-Авг-26, 06:30
	> Но он - в отличие от - это все _молча_ делал Вот. Именно поэтому цензура и нужна.
	Ответить | Правка | Наверх | Cообщить модератору

	348. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (-), 19-Авг-26, 14:33
	> каменных ножах деньги зарабатывал - сидит на улочке иджун, камушком-по-камушку тюк-тюк > - туристы довольны. Тоже бизнес, рыночная ниша, не удивлюсь даже если > и вполне себе прибыльная. Ну а что. Рынок штука такая - есть спрос, есть предложение. Кстати для freehck у меня ремарка: если цензура нужна, я не против того что RH хочет вымарать отстатки sysv init совсем. Позвольте предать забвению, выпилив совместимость, заимплементив ваши же пожелания - во весь рост :) Почему-то люди продвигающие некоторые стандарты - уверены что к ним то это уж точно не применят. А когда оказывается что применят - певым делом - и совсем не так как они это представляли - но лекала те же самые - почему-то жутко недовольны жизнью. Но так и не учатся ничему :D > - новое-прекрасное-будующее(будующего), и не надо ему этих наших ТЛЕТВОРНЫХ ВЕЯНИЙ, Эм... кстати... некоторые так то пошли чуть дальшее и сделали гипер-продвинутые версии технологии. Типа керамических ножей и инструментов. Они, кстати, вполне обладают достоинствами старинного протитипа - почти не тупятся. И это вполне себе достоинство, о котором говорят без стеснения. > вот оно освоил НОВУЮ ТЕХНОЛОГИЮ и по черный камень сейчас стучит > не другой камень, а вот - железкой, такой же как у > самого главного белого бваны, а все остальные просто НИАСИЛИЛИ... Внезапно, есть развитие технологии в виде керамических инструментов. Старая идея - с неиллюзорным апгрейдом, сохраняющим однако ключевые достоинства. И тут вы такой - не, мол, керамический ножик не то. Вот лучше купите у нас раскройную машину, вместе с заводскими корпусами, - ну и что что кредит даже внуки выплачивать будут, зато сможете резать хоть километры стали!
	Ответить | Правка | К родителю #289 | Наверх | Cообщить модератору

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

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

	8. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (-), 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ообщить модератору

	256. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от edo (ok), 16-Авг-26, 04:57
	> Вы видимо не в курсе что DISCARD - это лишь _хинт_ В мире, в котором есть rzat (и его аналог для nvme), это уже не просто хинт
	Ответить | Правка | Наверх | Cообщить модератору

	349. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (-), 19-Авг-26, 14:38
	>> Вы видимо не в курсе что DISCARD - это лишь _хинт_ > В мире, в котором есть rzat (и его аналог для nvme), это > уже не просто хинт Как бы вам сказать то? Вы по факту не сможете проверить что РЕАЛЬНО с тем или иным накопитеоем делает та или иная команда данная фирмвари и сколько там чего форенсикам остается после этого. Слишком дофига слоев трансляции и абстракций. То-есть, фирмвар может показать вам логическое смещение 0x100500 как забитое нолями - просто перевесив указатель и сделав ремап региона в таблице трансляций в какой-то erased. Заметьте, с инфо которое хранилось в изначальных блоках - вообще никто ничего делать как таковой не обязан был. Накопитель возвращает нули при запросе чтения 0x100500? Все, convention соблюден! Фича типа-поддерживается.
	Ответить | Правка | Наверх | Cообщить модератору

	355. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от edo (ok), 19-Авг-26, 15:09
	> Как бы вам сказать то? Вы по факту не сможете проверить что > РЕАЛЬНО с тем или иным накопитеоем делает та или иная команда > данная фирмвари и сколько там чего форенсикам остается после этого. Слишком > дофига слоев трансляции и абстракций. с этой точки зрения полностью согласен. речь была про то, что это уже не просто хинт как раньше *с точки зрения ОС* (накопители без rzat могут после trim отдавать что угодно, в том числе и "старые данные, а через 15 минут — некий мусор") и, насколько я знаю, вытаскивание данных из современных накопителей прямым чтением флеша — не такая уж и тривиальная задача, я бы сказал совсем нетривиальная. читал, что накопители с поддержкой sed (некоторые?) шифруют флеш всегда, даже если пользователь не запросил шифрование. и вам потребуется как-то вытащить из контроллера закрытый ключ. плюс алгоритмы избыточного кодирования не факт, что публичные используются.
	Ответить | Правка | Наверх | Cообщить модератору

	367. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (-), 19-Авг-26, 18:40
	> — не такая уж и тривиальная задача, я бы сказал совсем > нетривиальная. > читал, что накопители с поддержкой sed (некоторые?) шифруют флеш всегда, даже если > пользователь не запросил шифрование. и вам потребуется как-то вытащить из контроллера > закрытый ключ. плюс алгоритмы избыточного кодирования не факт, что публичные используются. Оно конечно не тривиальная - но если станет надо то все же решаемая. Поэтому всерьез уповать на то что trim и проч что-то как-то где-то... более-менее возыметь эффект может разве что команда security erase накопителя, там по крайней мере солидная площадь будет почищена и сильно много данных чисто технически негде будет осесть. Или несколько раз по всей площади стоража разным нетривиальным паттерном пройти - но это долго и все же без гарантий. И не file-level.
	Ответить | Правка | Наверх | Cообщить модератору

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

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

	127. "В systemd-journald спустя 6 лет признали проблему избыточной..."	–1 +/–
	Сообщение от Вася (??), 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ообщить модератору

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

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

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

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

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

	273. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+2 +/–
	Сообщение от BrainFucker (ok), 16-Авг-26, 12:53
	> И это причина по которой мир в целом предпочел - его. Никакой мир не предпочёл, тупо навязали вендорлок через крупнейшего вендора, остальные игроки какое-то время оставались на существовавших инструментах, но постепенно всё равно пришлось сдаться. Впрочем, никто особо и не использует journald, syslog по прежнему текстовый, докер тоже пишет джейсоны в свои текстовые логи, все прочие сервисы, apache, nginx, caddy и прочие тоже пишут в свои логи и у каждого свой формат. По дефолту в journald летят только stdout/stderr выхлопы процессов, запускаемых из systemd, но эти логи полезны только в случае когда сервисы неожиданно падают.
	Ответить | Правка | К родителю #13 | Наверх | Cообщить модератору

	350. "В systemd-journald спустя 6 лет признали проблему избыточной..."	–2 +/–
	Сообщение от Аноним (350), 19-Авг-26, 14:51
	> Никакой мир не предпочёл, тупо навязали вендорлок через крупнейшего вендора, остальные > игроки какое-то время оставались на существовавших инструментах, но постепенно всё равно > пришлось сдаться. Вот лично мне никто ничего не навязывал - я сам sd journal api разучил. Потому что колупать все эти голимые текстовички - с риском лохануться в парсинге если ремота злобная - такое себе. А вы даже не умеете nginx настраивать в сислог логить - вам вообще рано еще рассуждать о таких материях. И если мне сватают выбор из кривых педалей и энтерпрайз монстрятины - я выбираю появление mid-range решений. Это то что я на самом деле хотел. > Впрочем, никто особо и не использует journald, syslog по прежнему текстовый, Syslog вообще - api такое, для софта, man 3 syslog :D. Как он там реализован внутрях - да это его дело. И вот s-d journal одна из реализаций. И все что прога пуляет в апю сислога потом можно через апю s-d journal выцепить. В том виде как прога его записала, без особых возможностей ремоты вклиниться в какой там еще "парсинг строк". SD получает через апю сообщение. И отдает его мне, целиком. Юнитом "сообщение". А не "строка". Немного разный элемент обмена информацией. Я получаю - "сообщение лога" а не "строку". И даже если атакующий смог напхать переводов строк - это никак ему не поможет в таком случае. Я все равно в курсе что это - одно сообщение. И новых сообщений, с фэйковым айпи наппример, дурящими парсер - это в системе не сгенерит уже в таком виже. Так что левый айпи - в баню не попадет. > докер тоже пишет джейсоны в свои текстовые логи, все прочие сервисы, apache, > nginx, caddy и прочие тоже пишут в свои логи и у каждого свой формат. А в случае вот именно сислога - все же не надо париться что какой-то креативщик воткнет 0x0d, 0x0a, 0x0 и проч и сделает вместо 1 строки эн если та прога прошляпит - попутно накормив допустим автобаннер левой записью с левым айпишником, который он на отлично возьмет в оборот. И забанит что-нибудь не то. Можно вообще по факту обнаружения таких байтов посреди СООБЩЕНИЯ сразу автобан надолго давать - ибо явная попытка атаки или триггер жесткого бага в программе. > По дефолту в journald летят только stdout/stderr выхлопы А таки писать в сислог - умеют все кому не лень. И дефолты так то - не выбиты в камне. Меняются со временем по дистрам, да и переиграть их можно. > процессов, запускаемых из systemd, но эти логи полезны только в случае > когда сервисы неожиданно падают. Они полезны - чтобы забыть о всяком крапе типа логротейтов, кронов и прочих лоскутных одеял с отдельными конфигурациями в дюжине закоулков. Нарулить ОДНУ общесистемную политику вида "сислог не более 100 мег" мне явно проще чем трахаться со всеми этими вашими логротейтами и прочим непотребством. А заодно и кроны всякие не будут спамить потугами логина в логи. И все это будет управляться значительно менее криво. А вы можете юзать те педали если хотите - но без меня.
	Ответить | Правка | Наверх | Cообщить модератору

	107. "В systemd-journald спустя 6 лет признали проблему избыточной..."	–1 +/–
	Сообщение от 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 лет признали проблему избыточной..."	+1 +/–
	Сообщение от 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ообщить модератору

	290. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от User (??), 16-Авг-26, 18:50
	Попробовал посчитать сколько раз употреблено местоимение "я" - на третьем десятке сбился. Очень рад за вас, что вы - в отличие от всей остальной индустрии - идете в ПРАВИЛЬНОМ направлении! Идите дальше и никуда-никуда не сворачивайте...
	Ответить | Правка | Наверх | Cообщить модератору

	351. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (350), 19-Авг-26, 14:57
	> Попробовал посчитать сколько раз употреблено местоимение "я" - на третьем десятке сбился. Расписываться за вас, весь мир и проч - это слишком масштабно и моей прерогативой не является :) > Очень рад за вас, что вы - в отличие от всей остальной индустрии - идете > в ПРАВИЛЬНОМ направлении! Идите дальше и никуда-никуда не сворачивайте... Я вообще совсем не часть той индустрии. This is intentional.
	Ответить | Правка | Наверх | 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ообщить модератору

	326. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (-), 18-Авг-26, 02:33
	"Почему SQLite не используют как главный логгер Linux?Разработчики systemd-journald на этапе проектирования рассматривали SQLite, но отказались от него. И вот почему:Проблема параллельной записи (Concurreny):Представьте, что на вашем компьютере одновременно работают сотни процессов (ядро, браузер, драйверы, аудиосервер). Если в системе что-то происходит, они все одновременно начинают сыпать сообщениями. SQLite при записи блокирует весь файл базы данных. Из-за этого процессы выстраивались бы в огромную очередь, и система начала бы жутко тормозить.Баг с износом SSD стал бы еще хуже:SQLite — это транзакционная база данных (ACID). Чтобы данные не повредились при внезапном отключении питания, она использует механизм WAL (Write-Ahead Log) илиjournaling. Это значит, что любая запись строки в 100 байт приводила бы к двойной или тройной перезаписи секторов на диске. Наш баг с Write Amplification в journald на базе SQLite стал бы еще разрушительнее.Повреждение при сбоях:Если компьютер резко выключить из розетки в момент, когда SQLite зажимает транзакцию, файл базы данных с высокой долей вероятности может «обидеться» и полностью повредиться (corrupted). Для системных логов Linux, которые должны сохранять информацию именно в момент краха системы, это недопустимо"
	Ответить | Правка | Наверх | Cообщить модератору

	352. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (350), 19-Авг-26, 15:01
	> когда SQLite зажимает транзакцию, файл базы данных с высокой долей вероятности > может «обидеться» и полностью повредиться (corrupted). Для системных логов > Linux, которые должны сохранять информацию именно в момент краха системы, это > недопустимо" Ну я так то догадываюсь что относительно мелкий task specific key value - в целом будет работать зело шустрее generic SQL штуки... :) И вот именно итерировать сообщения сервиса туда-сюда, плюс-минус пару индексов и проч ее таки - хватит. И это все довольно неплохо работает. Вон там какие-то типы про 100 rps вещают. А я о некоторых вещах догадался когда лог nginx за день стал - 10 гигс. И тут оказалось что всякий крап типа fail2ban может ресурсов жрать - больше чем сами атакующие :D
	Ответить | Правка | Наверх | Cообщить модератору

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

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

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

	23. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+4 +/–
	Сообщение от Аноним (-), 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ообщить модератору

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

	354. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (-), 19-Авг-26, 15:06
	> Так если он может произвольно модифицировать записи, он и размер сможет подделать > или весь файл попортить до нечитаемости. Не совсем так. Если некто в протокольное поле втулил допустим юзернейм вида "вася\x0d\x0a 13:33:37 whatever - и вообще - я Петя!" - text based парсинг на этом может и на";№%ться если сервис это дело прошляпит. И читая сие по строкам можно будет получить это как уже 2 разные сообщения. При том "сообщения" вида 13:33:37 whatever - и вообще - я Петя! ...сервис на самом деле не генерил никогда и это лишь - факап парсинга. Основанный на том факте что "сообщение" и "строка" в обещм случае - не синонимы. А в случае логинга через сислог и анализа через апю sd - я не оперирую "строками". Я оперирую - "сообщнииями", с произвольным контентом. И знаю размер всего сообщения от и до. Поэтому его контент как новое сообщение с левыми полями уж точно не рассмотрю, вот хоть как.
	Ответить | Правка | Наверх | Cообщить модератору

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

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

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

	274. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от BrainFucker (ok), 16-Авг-26, 12:59
	> А альтернативы то какие? Сидеть с голым задом или огроменные энтерпрайзные монстры? А причём тут голый зад? Apache, nginx или caddy разве пишут access.log в journald? Да вроде нет, по прежнему пишут в текстовые логи. Докер тоже пишет stdout/stderr сервисов в свои json логи. Так-то мало кто в своё ПО добавлял поддержку логгирования через journald, у всех свой формат по прежнему.
	Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

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

	341. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (-), 19-Авг-26, 13:12
	> А причём тут голый зад? Apache, nginx или caddy разве пишут access.log > в journald? Да вроде нет, по прежнему пишут в текстовые логи. Т.е. ман на nginx - вы не смогли прочитать? Представляете, nginx умеет в сислог. И большая часть уважающего себя софта умеет - syslog() задолго до системды появился и не умеет его только ленивый. После этого можно забыть про все ваши текстовички, и нечисть типа logrotate вместе с ними! > Докер тоже пишет stdout/stderr сервисов в свои json логи. stdout при рулении чеоез s-d - тоже в логи пишется. Это ж не sysv педали... > Так-то мало кто в своё ПО добавлял поддержку логгирования через journald, у всех > свой формат по прежнему. ПО достаточно уметь syslog() - man 3 syslog. Этого хватит. S-d тоже сие получать - умеет, не хуже остальных логгеров. И вот так - прога посылает сообщение логгеру. Логгер получает его как есть. И, конечно, знает при этом точное содержимое как отдали - и размер сообщения. Не надо пытаться угадать размер записи самому в своем парсере, уповая что ремота не сможет втулить CR/LF/0x0 в поля протокола или что там еще. Если я знаю размер буфера я могу его парсить "от и до".
	Ответить | Правка | К родителю #274 | Наверх | 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 лет признали проблему избыточной..."	–2 +/–
	Сообщение от Аноним (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 лет признали проблему избыточной..."	–1 +/–
	Сообщение от Аноним (236), 15-Авг-26, 23:01
	> https://habr.com/ru/articles/912682/ Ну так для сведения... 1) У мня на моих нагрузках - я никогда все то не видел. 2) И кстати да, я юзаю MGLRU уже черт знает сколько времени. Как вы уже догадались - я не буду грохать сотни моего времени на воспроизведение проблемы которой у меня даже нет чтобы порадовать какого-то типа с хабры. У него проблемы mem management? Во, киздато - пусть гражданин идет к господам из mm/ и решает это с ними. И да, если вы брякнете про какие-то васян-"моды" ядра в майнлайне вас конечно мигом посичтают за гамно и не будут с вами работать. Таков путь. То-есть вы будете до упора юзать свои васян-моды в результате. А так - жил был баг. Оказавшийся аж в mm/ - и таки долбавший вот именно меня и мои конфиги. Через сутки его почему-то не стало. Может потому что я регресс и словил и бисект выкатил, например? Но я не собираюсь это делать для вообще всех багов на планете - у меня на это "по дефолту" тупо нет ни времени ни желания и есть куча дел интереснее траха с чужими багами которые меня никак не импактят. Если б я был майнтайнером mm/ я бы конечно сказал вам иные слова. Но я не майнтайнер mm/ и вы просто не по адресу.
	Ответить | Правка | Наверх | Cообщить модератору

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

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

	262. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (262), 16-Авг-26, 09:43
	Я ровно этот баг видел, обновляя линукс в гостевой вируалке с вендой на хосте. Потом что-то похожее  обновляя msys2. Венда вообще паршиво с кучей мелких файлов работает. А вот на линуксе у меня только иксы регулярно подвешиваются при закритии хромиума (и немного при открытии), на вейланде фризов не припомню -- окна вешаются и показывается анимация. А баги с io были только с некачественными флешками, и, поскольку их у меня не осталось, я подобное не встречал уже давно.
	Ответить | Правка | К родителю #200 | Наверх | Cообщить модератору

	369. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (16), 19-Авг-26, 21:51
	> А баги с io были только с некачественными флешками, и, поскольку > их у меня не осталось, я подобное не встречал уже давно. Линух с неких пор подтвикал эвристику размера dirty для 12309 и если флеха тормозная - для нее немеряный буфер просто не отращивается. Так что и его выжимка по полчаса более не происходит. Это и есть часть фикса именно 12309. Но да - paging можно загнать в ряд иных странных ситуаций. Вот только 12309 они не являются...
	Ответить | Правка | Наверх | 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ообщить модератору

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

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

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

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

	270. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним 80_уровня (ok), 16-Авг-26, 12:30
	Ты б ещё спросил "Ну что, теперь системд не будет?"
	Ответить | Правка | К родителю #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 лет признали проблему избыточной..."	+2 +/–
Сообщение от Аноним (24), 15-Авг-26, 01:30
Я вижу здесь корреляцию со слегка возросшей ценностью SSD, сейчас уже не так просто "купить новый, а старый выкинуть". Людям стало не так легко расставаться с вещами. Надо теперь на браузеры переключаться и постить туда баги, там тоже конь не валялся.
Ответить | Правка | Наверх | Cообщить модератору

	27. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+4 +/–
	Сообщение от Аноним (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ообщить модератору

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

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

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

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

	278. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от ТолянКодерСлесарь (?), 16-Авг-26, 13:17
	Да ладно, это всего лишь подорожание Ssd, Озу, примерно как в 2017, на волне популярности майнинга.
	Ответить | Правка | К родителю #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ообщить модератору

	299. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (298), 17-Авг-26, 06:19
	Ещё дольше ждут когда IPv6 гитхаб оъявлять начнёт, чтобы истинные луддиты присосавшиеся к любымим UI в CircusOS на купленных у Clowns LLC наконец-то выкинули эти все блэкбоксы с подписками на маршрутную таблицу, потому что только так у них "IPv4 всё работает"
	Ответить | Правка | Наверх | Cообщить модератору

	319. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от zionist (ok), 17-Авг-26, 18:21
	Ты их сглазил! https://www.githubstatus.com/incidents/zkxwbgr0cnmx Update Pages is experiencing degraded performance. We are continuing to investigate. Posted 10 minutes ago. Aug 17, 2026 - 15:10 UTC Update API Requests is experiencing degraded availability. We are continuing to investigate. Posted 18 minutes ago. Aug 17, 2026 - 15:01 UTC Update Webhooks is experiencing degraded availability. We are continuing to investigate. Posted 21 minutes ago. Aug 17, 2026 - 14:58 UTC Update We are experiencing high error rates around 20% for web experiences and api traffic. Archive downloads and raw repository content downloads are experiencing an approximate 50% error rate. SAML and OIDC authentication, SCIM, and Team Sync are also impacted. We are currently performing mitigations based on our investigation thus far and are monitoring for improvement. Posted 22 minutes ago. Aug 17, 2026 - 14:58 UTC Update Actions is experiencing degraded availability. We are continuing to investigate. Posted 22 minutes ago. Aug 17, 2026 - 14:58 UTC Update Pull Requests is experiencing degraded availability. We are continuing to investigate. Posted 25 minutes ago. Aug 17, 2026 - 14:54 UTC Update Issues is experiencing degraded availability. We are continuing to investigate. Posted 30 minutes ago. Aug 17, 2026 - 14:49 UTC Update Pull Requests is experiencing degraded availability. We are continuing to investigate. Posted 34 minutes ago. Aug 17, 2026 - 14:45 UTC Update Copilot is experiencing degraded availability. We are continuing to investigate. Posted 48 minutes ago. Aug 17, 2026 - 14:31 UTC Update We are experiencing high error rates around 20% for web experiences and api traffic. Archive downloads and raw repository content downloads are experiencing an approximate 50% error rate. SAML and OIDC authentication, SCIM, and Team Sync are also impacted. Investigations are on-going and we will continue to provide updates as we discover more information. Posted 55 minutes ago. Aug 17, 2026 - 14:24 UTC Update We are experiencing high error rates around 20% for web experiences and api traffic. Archive downloads and raw repository content downloads are experiencing an approximate 50% error rate. Investigations are on-going into the root cause, and updates will continue to be provided as we investigate. Posted 1 hour ago. Aug 17, 2026 - 14:04 UTC Update Pull Requests is experiencing degraded performance. We are continuing to investigate. Posted 1 hour ago. Aug 17, 2026 - 13:58 UTC Update Issues is experiencing degraded performance. We are continuing to investigate. Posted 2 hours ago. Aug 17, 2026 - 13:46 UTC Update We are seeing an approximate 20% error rate across numerous experiences including Pull Requests, Issues, and others. Investigations are currently under way and we will be posting updates as they become available Posted 2 hours ago. Aug 17, 2026 - 13:45 UTC Update Webhooks is experiencing degraded performance. We are continuing to investigate. Posted 2 hours ago. Aug 17, 2026 - 13:44 UTC Update Actions is experiencing degraded performance. We are continuing to investigate. Posted 2 hours ago. Aug 17, 2026 - 13:42 UTC Update API Requests is experiencing degraded performance. We are continuing to investigate. Posted 2 hours ago. Aug 17, 2026 - 13:41 UTC Investigating We are investigating reports of impacted performance for some GitHub services. Posted 2 hours ago. Aug 17, 2026 - 13:40 UTC
	Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

	295. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+1 +/–
	Сообщение от SelfPerfection (ok), 16-Авг-26, 23:50
	>> мейнтейнеры проекта изменили риторику и начали работу над оптимизацией механизмов сброса кэша и структуры хранения индексов journald > Ссылка? Оригинальный пост на реддите некорректен. Там приняли https://github.com/jleeuwes/komputiloj-mirror/commit/f425c80... коммит постороннего Васяна в его личный конфиг системы за исправления от разработчиков в SystemD.
	Ответить | Правка | К родителю #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 лет признали проблему избыточной..."	–1 +/–
	Сообщение от Аноним (123), 15-Авг-26, 12:45
	Считать системд примером качественного софта могут только те, кто никогда не заглядывал в его исходники.
	Ответить | Правка | К родителю #48 | Наверх | Cообщить модератору

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

	370. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (16), 19-Авг-26, 21:54
	> содержащих данные. Программа должна уметь объяснять системе что делать. Давно можно > использовать Huge Pages, но в работе с файлами она должна указать С ними тоже не все так просто - если поврубать THP то при ряде нагрузок начнет жраться радикально больше RAM. Если страница 2 мега, а вот прямо сейчас от нее юзается лишь 1 мег - то - пардон - мег памяти продолбан вникуда. Потому что страница это все ж атомарный юнит. И там возникают еще куча проблем с коллапсом этого всего и дефрагом. Так что поврубав эти кульные плюшки можно заметить что сие не совсем бесплатно было.
	Ответить | Правка | Наверх | Cообщить модератору

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

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

	300. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (298), 17-Авг-26, 06:27
	Просто защитники systemd ни разу не пробовали парсить текстовые файлы построчно, даже пережатые или упакованные в архивы. Я каждый раз в осадке с того как долго journald на всех компах где я работал пытается найти 100Кб логов одного сервиса, при том что тот же самый проц без проблем перелопачивает десятки текстовых файлов в десятки других текстовых файлов и ещё успевает открыть 20 зипок, разжать и пропарсить xml, выдать такие же файлы и пропарсить их по несколько раз пока этот же объём информации пытается выдать journald. И это я ещё не параллелил все задачи где возможно, потому что оно и так в реалтайме считай происходит.
	Ответить | Правка | К родителю #234 | Наверх | Cообщить модератору

	303. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от freehck (ok), 17-Авг-26, 06:39
	> Я каждый раз в осадке с того как долго journald на всех компах где я работал пытается найти 100Кб логов одного сервиса Ну а кстати вполне очевидно, почему оно так. В силу архитектуры journald найти нужные строчки он может относительно быстро, а вот выдернуть их и вывести на экран — увы, нет. Накладных расходов целая гора: там же отдельные операции чтения на каждую запись...
	Ответить | Правка | Наверх | Cообщить модератору

	309. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (298), 17-Авг-26, 14:14
	freehck запретил отвечать на свои сообщения, поэтому так. Я не вижу как journald "быстро находит" логи, но просто "долго выводит их на экран". Вывод в cat режиме скорости не добавляет вообще, тут дело вообще не в форматировании вывода (который для 100Кб информации и так должен быть моментальным). Скорее всего просто формат файлика логов г-но и алгоритм поиска по этому формату очень неэффективный. Хотя казалось бы, раз уж сделали бдшку вместо потока логов быстро пробежаться по 10 Мб бдшке из которых нам нужно 100 Кб проблем не должно вызывать.
	Ответить | Правка | К родителю #300 | Наверх | Cообщить модератору

	312. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от freehck (ok), 17-Авг-26, 14:28
	> Скорее всего просто формат файлика логов г-но и алгоритм поиска по этому формату очень неэффективный. Да, именно так. Я про то же самое. Подробнее расписал в #60.
	Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

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

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

	254. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+4 +/–
	Сообщение от Норм (?), 16-Авг-26, 04:07
	А вы забыли уже как его втащили? В дебиан внезапно в обход всей этоц комунити демократии, что привело к уходу ключевых разрабов и созданию дувеан. В Арч чел с кнопкой просто всех послал на 3 буквы мол мы современные, а так как системда будущее (на тот момент вообще не юзабельное и не наступившее) а арч у нас блилинг еже современный то... А кто ему про будущее сообщил? Настрадамус небось. Я хорошо помню. Если коротко, решения не технического характера. О их причинах можно подумать. Для убунты и прочего корпротива все просто - копируем редхат(и паразитируем заодно). Там вопроса не стояло. А кто еще его себе вставил? На помойке окажется ровно в тот момент как оба владельца МС и редхат потеряют интерес. Мистики большой нет. Как и загадки почему оно такое багованное.
	Ответить | Правка | Наверх | Cообщить модератору

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

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

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

	255. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+1 +/–
	Сообщение от Норм (?), 16-Авг-26, 04:12
	1. Сообщество эту хрень не хотело и не просило. А вот даже на оборот. 2. В системде, давайте проверю, 512 открытых пулл реквестов. Пару месяцев назад были тысячи, не думаю что они их вмержери, скорее просто отклонили. Другими словами, двум челам с правами мержа нафиг ненужна и не интересна помощь сообщества. Им за это не платят.
	Ответить | Правка | К родителю #59 | Наверх | Cообщить модератору

	371. "В systemd-journald спустя 6 лет признали проблему избыточной..."	–1 +/–
	Сообщение от Аноним (16), 19-Авг-26, 21:59
	> 2. В системде, давайте проверю, 512 открытых пулл реквестов. Пару месяцев назад > были тысячи, не думаю что они их вмержери, скорее просто отклонили. Я знаю людей у которых - мержили. И да, они васяны васянами. Но PR полезный - и его мержили. Почему нет? Это у опеннетчиков теории заговора везде. На правах теорий заговоров, у большинства опеннетчиков так то уровень апломба не соответствует уровню квалификации. И они удивляются что их величеств везде посылают. Видите, в эту игру с теориями заговоров могут играть и двое :) > Другими словами, двум челам с правами мержа нафиг ненужна и не интересна > помощь сообщества. Им за это не платят. Чего б это от халявной то работы уважающий себя корп отказался бы?! Просто не все йогурты одинаково полезны, и давать шибко ретивым "фиксерам" не понимающим весь импакт что попало творить - тоже ну такое себе, отливается.
	Ответить | Правка | Наверх | Cообщить модератору

	380. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Норм (?), 20-Авг-26, 03:02
	Капец вы веселый реверанс сделали. Но я не копр, не по назначению откланялись. Хотя может это такой сарказм был, в 2026 уже разницы нет.
	Ответить | Правка | Наверх | 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 лет признали проблему избыточной..."	–1 +/–
Сообщение от Аноним (82), 15-Авг-26, 08:32
А зачем вообще простому смертному юзеру логи?
Ответить | Правка | Наверх | Cообщить модератору

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

	161. "В systemd-journald спустя 6 лет признали проблему избыточной..."	–2 +/–
	Сообщение от Аноним (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 лет признали проблему избыточной..."	–2 +/–
	Сообщение от Аноним (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 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (209), 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ообщить модератору

	263. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Гость (??), 16-Авг-26, 10:02
	в fedora всё пишется в /var/log/journal/, только в rhel пока нет
	Ответить | Правка | К родителю #119 | Наверх | Cообщить модератору

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

	246. "В systemd-journald спустя 6 лет признали проблему избыточной..."	–1 +/–
	Сообщение от Аноним (-), 16-Авг-26, 00:53
	> Бесят проги, которые используют накопители как помойку. > Многие сразу создают .log файл при запуске, даже когда нет ошибок (Xorg.0.log) Да уж... вон там на компе немолодой ssd - протерся аж на 5 процентов ресурса за 10 лет! Гадский системд, лет за 200 таки дожмет ssd до кондиции :). Интересно, а моему скелету на кладбище будет не пофигу ли случайно к тому моменту уже? Ну так, просто вопрос такой.
	Ответить | Правка | Наверх | Cообщить модератору

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

	272. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (175), 16-Авг-26, 12:41
	Уже всё было написано давно. Что использует Гугл в Хромосе? Апстарт.
	Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

	247. "В systemd-journald спустя 6 лет признали проблему избыточной..."	–2 +/–
	Сообщение от Аноним (-), 16-Авг-26, 00:55
	> Они по сути ссылались ан абстрактное понимание уровня BTRFS для которой нормально > убивать твердотельные накопители адской записью. Systemd так то достаточно сообразителен чтобы по дефолту на дире с логами nocow ставить. Все же эти господа - системные инженеры и знают свое дело. Независимо от того нравится это местным или нет, их квалификация говорит за себя в таких мелочах. И квалификация опеннетчиков - тоже. Но, увы, с разным знаком.
	Ответить | Правка | К родителю #166 | Наверх | 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ообщить модератору

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

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

	302. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (298), 17-Авг-26, 06:37
	Недавно он как-то не так создал как потом выяснилось эскиз какой-то фотки или видео и продолжал крашится когда переходил в папку загрузок. 7zip открывал ту же папку и те же файлы без проблем. Помогло только абстрагирование от здравого смысла, бубен и догадка что надо попробовать почистить все возмодные кэши перед тем как опять переустанавливать шиндуз.
	Ответить | Правка | К родителю #258 | Наверх | Cообщить модератору

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

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

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

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

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

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

	291. Скрыто модератором	+/–
	Сообщение от Аноним (291), 16-Авг-26, 19:24
	Скока новых севисов запилил? Одной арабской цифры близкой к нулю, хватитЪ?
	Ответить | Правка | Наверх | Cообщить модератору

	357. Скрыто модератором	+/–
	Сообщение от Аноним (-), 19-Авг-26, 15:20
	> Скока новых севисов запилил? Одной арабской цифры близкой к нулю, хватитЪ? Неа, уже совсем никак. Пошло г... по трубам и теперь часть этого добра околоконвейерными методами штампуется. У меня только лично моих проектов - больше. А юнитов sd на все оказии - пришлось диру с поддирами делать по тематике.
	Ответить | Правка | Наверх | Cообщить модератору

266. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+2 +/–
Сообщение от LaunchWiskey (ok), 16-Авг-26, 11:54
Всё, что надо знать об архитектуре и качестве решений systemd. А уж как в том обсуждении лично Пёттеринг  вонял: "Вы все <рогатое парнокопытное> и не понимаете, как работает файловая система. Даже смотреть на issue не будем!".
Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

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

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

	308. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Неприятный мужчина (?), 17-Авг-26, 13:57
	И еще насчет работы. Мир BSD не так колбасит, там все знания которые прилипли - все твое. В Линуксе постоянно переучиваешся - регулярно меняются большие подсистемы. Я уже молчу про 100500 дистрибутивов. И хорошо если проф админ - не проблема. А если нет, но где-то рядом - тут уже все хуже. А с опытом устаешь от новостей, хочется сесть туда где потише и спокойно рыть вглубь.
	Ответить | Правка | К родителю #285 | Наверх | Cообщить модератору

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

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

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

	287. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от freehck (ok), 16-Авг-26, 17:33
	> Мужики, давайте к нам в BSD. Мы такой фигней не занимаемся. Почти 70 лет непрерывного экспириенса, не съезжая с юниквэяЪ. Не, ребят, спасибо. При всём уважении к BSD, в Linux-системах тусовочка побольше и денежные реки тут пошире текут. К вам может зайдём, если файлохранилище хорошее понадобится. ;)
	Ответить | Правка | К родителю #279 | Наверх | Cообщить модератору

	294. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+1 +/–
	Сообщение от ы (?), 16-Авг-26, 22:05
	О даа, при всё _уважении_. Стооолько уважения прям в каждом местном комментарии при любом упоминании bsd. Тусовочка побольше - эт да. Как говорили в 00x линксоиды (их ч.с.в тогда ещё не окончательно опухло)? "Миллионы мух не могут ощибаться", да? Ну-с, поздравляю примкнувших. Свою системду вы вполне заслужили.
	Ответить | Правка | Наверх | Cообщить модератору

	323. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+2 +/–
	Сообщение от _ (??), 17-Авг-26, 18:41
	А помните - "Мы хотим переманить юзеров с форточки!(С)" Поздравляю, переманили ... теперь линуксоид и вантузятник - суть разные проекты одного папика ;-D
	Ответить | Правка | Наверх | Cообщить модератору

	373. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (373), 19-Авг-26, 22:18
	> А помните - "Мы хотим переманить юзеров с форточки!(С)" > Поздравляю, переманили ... теперь линуксоид и вантузятник - суть разные проекты одного > папика ;-D Зато BSDшники хотели доказывать всем что они самые умные, самые крутые, самоутверждатся за чужой счет тыкая всех носом в RTFM и проч. И достигли в этом определенных успехов. Так что пользоваться этим только очень узкая горстка фриков и захотела, а все остальные пошли в указанном направлении. Представляете, иногда можно - приколоться и последовать driving direction. Посмотреть как посылавшему такой расклад на практике! :D
	Ответить | Правка | Наверх | Cообщить модератору

	372. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (373), 19-Авг-26, 22:16
	> О даа, при всё _уважении_. Стооолько уважения прям в каждом местном комментарии > при любом упоминании bsd. Ребят, вам надо бы в зеркало посмотреться у кого юзеры пингвина этому научились :). Когда пингвин ходил пешком под стол и я был нуб - я помю коменты BSDшников относительно линя. А потом - колесо фортуны крутанулось в другую сторону, пингвин окреп, задвинул BSD куда подальше... и господа которе вон тем вещали вон то - познали парадигму "долг платежом красен". С превышением. Зато это - понятный таким формат. И всяким freehck, похам-нахам и прочим умкам я пожелаю - того же самого, в максимальном виде. Не зря говорят - относитесь к другим так как вы бы хотели чтобы относились к вам :) > Тусовочка побольше - эт да. Как говорили в 00x линксоиды (их ч.с.в > тогда ещё не окончательно опухло)? "Миллионы мух не могут ощибаться", да? > Ну-с, поздравляю примкнувших. Свою системду вы вполне заслужили. Более того. Нас больше по определенным причинам... - Приходишь на форум BSD, спрашиваешь. В ответ ор - "ламер!", "RTFM!", "тупица!" и что там еще. - Приходишь к линуксоидам. Эти с энтузиазмом помогут. И даже если знали меньше, не такие уберпро и проч - а на практике, вот, полезнее и дружелюбнее. Так экосистема и развивается. А потом вон те придут и впрягутся, насыпят денег, починят проблемы, ... - потому что им понравилось и они решили что такая экосистема должна сохраниться и развиваться дальше. Такое вот отличие. Зачем мне париться сохранением BSD и благополучием всяких похов-нахов, умок, user и прочих жлобских проприетариев которые мне - стакан воды не поднесут, даже если я помирать буду, а им - дай-дай-дай, нахаляву, yada-yada. Не все люди заслуживают чтобы для них делать бесплатные работы.
	Ответить | Правка | К родителю #294 | Наверх | Cообщить модератору

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

	335. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от freehck (ok), 18-Авг-26, 18:24
	> Потому что вы так жадно жрали с лопаты - что угробили все альтернативные проекты. А вот не надо нам приписывать свои факапы. Надо было лицензировать Kernel под GPL — глядишь, и к вам инвестиции потекли бы. Но поезд уже давно ушёл, поздняк метаться. Я согласен, у Linux-систем есть проблемы с корпами и лопатами. Но у вас их нет лишь потому, что вы до этих проблем просто не доросли. Пошли б вы в рост — столкнулись бы ровно с тем же самым. Я тебя не понимаю, нах. Мы тут вроде бы все в одной лодке. Чего ты быкануть-то вдруг решил?
	Ответить | Правка | Наверх | Cообщить модератору

	336. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от нах. (?), 18-Авг-26, 18:58
	> А вот не надо нам приписывать свои факапы. Надо было лицензировать Kernel > под GPL — глядишь, и к вам инвестиции потекли бы. Но чтобы получить такую же дрянь? Инвесторы - они требуют плясать с ними тех кого ужинали. (но я тебя огорчу, gpl к этому ни малейшего отношения не имеет. Только решение IBM кого им легче было в тот момент окрутить ужинать. У проекта с единоличным божеством с пальцем шансов конечно было больше.) > Я тебя не понимаю, нах. Мы тут вроде бы все в одной > лодке. Чего ты быкануть-то вдруг решил? моя лодка давно уже ушла. Я больше не пользуюсь линуксами для бытовых целей и не собираюсь их чинить. Я просто наблюдаю с бережка. (а корпоративные стораджи мне совершенно не жалко)
	Ответить | Правка | Наверх | Cообщить модератору

	338. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от freehck (ok), 19-Авг-26, 07:25
	>> А вот не надо нам приписывать свои факапы. Надо было лицензировать Kernel >> под GPL — глядишь, и к вам инвестиции потекли бы. Но > чтобы получить такую же дрянь? Инвесторы - они требуют плясать с ними тех кого ужинали. А без инвестиций — развитие зиждется исключительно на голом энтузиазме отдельных личностей, коих ничтожно мало. Это рельсы в пропасть. Я конечно понимаю, что для фанатичных BSD-шников это шило на мыло и всё равно дрянь, но IT-продукты на чём-то всё же строить надо. > но я тебя огорчу, gpl к этому ни малейшего отношения не имеет Ну ты не прав. GPL является той самой причиной, по которой корпы объединились именно вокруг Linux. Там ведь далеко не только IBM вписался.
	Ответить | Правка | Наверх | Cообщить модератору

	339. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от нах. (?), 19-Авг-26, 07:57
	> А без инвестиций — развитие зиждется исключительно на голом энтузиазме отдельных личностей нет, всегда есть те чей бизнес зависит от твоего решения. Просто таки да, это будут не миллиарды. Но те миллиарды - целевые. На системдрянь, вафлянд и переписывание графического стека лин00ps онли. А деньги Коума можно было бы потратить и не на лекции о гендерных штудиях. Пока линукс делали в основном вторым способом - он мне нравился больше чем freebsd (включая и то что делала ранняя RH). А продукция IBM стала тем чем всегда была - продукция IBM. Начиная с system360 и заканчивая (IBM!) OS/2.
	Ответить | Правка | Наверх | Cообщить модератору

	340. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от freehck (ok), 19-Авг-26, 09:47
	>> А без инвестиций — развитие зиждется исключительно на голом энтузиазме отдельных личностей > всегда есть те чей бизнес зависит от твоего решения Ты сравниваешь слона с мухой. Когда я пишу "в проект нет инвестиций", естественно это не значит "совсем нет". Это значит, что инвестиции пренебрежимо малы по сравнению с конкурентом. > Но те миллиарды - целевые Ты недооцениваешь сигналы бизнеса, которые подаются индустрии корпами. Когда корпы инвестируют в проект — бизнес размером поменьше отлично считывает, что корпы проекту доверяют, и вкладываются, и его интерес к проекту тоже повышается: работать с таким проектом надёжнее, нежели с проектом без инвестиционной поддержки корпами. > А продукция IBM стала тем чем всегда была - продукция IBM. Будем честны: почти весь код, на котором живёт наша любимая IT-индустрия, с точки зрения любого мало-мальски опытного хакера — дрянь. Перефразируя Тютчева: "код написанный есть говно". Что ж нам теперь, из-за этого остановиться и ничего не делать? Нет, конечно. Живём.
	Ответить | Правка | Наверх | Cообщить модератору

	374. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (-), 19-Авг-26, 22:30
	> чтобы получить такую же дрянь? Инвесторы - они требуют плясать с ними > тех кого ужинали. И получили в результате - дырку от бублика. Если это типа-лучше - какие проблемы?! Кушайте свое BSD, не обляпайтесь. Ой, чойта вы дрисняточку продвигаете? Оказывается оборудования понаделали во, дров писать умеет во, и не работает - ни-че-во?! Какие гроссмейстеры. Всех переиграли. Даже себя! > (но я тебя огорчу, gpl к этому ни малейшего отношения не имеет. GPL имеет отношение к инвестициям, отдаче в проект, и тому чтобы не быть так по жизни лохом. Торвальдс вот - показал талант годного манагера, припахав акул бизнеса. А BSD показали что в управление проектами не умеют чуть менее чем нихрена. > Только решение IBM кого им легче было в тот момент окрутить > ужинать. У проекта с единоличным божеством с пальцем шансов конечно > было больше.) BSD был раньше и ничто не мешало IBM и прочим инвестировать - в него. Кроме того что с одной стороны эти лабухи с своим пофигизмом на суд с AT&T нарвались, с другой их юзали потому что "лицензия позволяет". А в какой-то момент windriver так то случайно узнал что думают кастомеры на эту тему - и выбросил свое проприетарное BSD в пользу Linux. Иначе кастомеры бы выбросили - уже WindRiver :). Кто ж в современном то мире за проприетарное BSD будет еще и платить... >> лодке. Чего ты быкануть-то вдруг решил? > моя лодка давно уже ушла. Я больше не пользуюсь линуксами для бытовых > целей и не собираюсь их чинить. Я просто наблюдаю с бережка. > (а корпоративные стораджи мне совершенно не жалко) Ну у вас там получились отношения жабы и гадюки, в общем, не возражаю чтоб на ваш берег упал большой метеорит или ядерный заряд когда я отплыву подальше.
	Ответить | Правка | К родителю #336 | Наверх | Cообщить модератору

	383. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от нах. (?), 20-Авг-26, 08:59
	> И получили в результате - дырку от бублика. Лучше голодать чем что попало есть. (жрать дерьмо с лопаты и нахваливать) Но подобным тебе шакаляткам никогда этого не понять, пока не станет поздно. А оно станет, они раздавят в лепешку и твою хатку с краю - просто потому что под ногу попала, и вряд ли ждать придется долго. А ты - при этом окажешься на помойке, потому что тут доказал что _ничегошеньки_ не умеешь и не знаешь элементарных вещей (даже про свои же фетиши). А проблему лудшего виндовс чем виндовс _мы_ решать никогда и не собирались. Нам был юникс нужен а не более лудший десктоп 6ешпл@атно. Мы пережили 90е, когда подобные шакалята превозносили то дос, то os/2, то переметнулись в NT, "а этот ваш никому ненужно". Переживем и эти, когда и линукс IBM отправит на свое кладбище, она еще ни разу не промахнулась. > BSD был раньше и ничто не мешало IBM и прочим инвестировать - в него. мешало. То что они - не продавались.
	Ответить | Правка | Наверх | Cообщить модератору

	405. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (-), 23-Авг-26, 22:37
	>> И получили в результате - дырку от бублика. > Лучше голодать чем что попало есть. И к чему пришли? Из продов вылетели, разработчиков нет, а если кто десятку юзает - вероятность что ему приспичит писать драйверы и системный софт под BSD "где-то там" понятная. > Но подобным тебе ... не понять, Я кушаю для ЛИЧНО СЕБЯ технологии которые продвигаю. Так честнее, лучше работает, и вопросов "почему я этим должен заниматься?" не вызывает. В отличие от. А когда господа из других ос - с сервисными манагерами и бинарными логами/базами - вещают за вэи - ну, э, лол. Не, так это не работает, господа. Так же как директор Кока Колы пьющий Пепси на публике - не убедит никого что Кока Кола - лучше. > пока не станет поздно. Проблемы имхо стоит решать по мере их поступления. Может это все не при моей жизни случится. А вон там господа наслаждаются "улучшениями качества обслуживания" и мерзкими EULA уже сегодня. > потому что тут доказал что _ничегошеньки_ не умеешь и не знаешь > элементарных вещей (даже про свои же фетиши). Я теперь ничего не умею и в апях sd-journal :). И какая разница что говорят на опеннете если приблуды worksforme? Как говорится, делай что должен и будь что будет. > А проблему лудшего виндовс чем виндовс _мы_ решать никогда и не собирались. И именно поэтому мне с вами не по пути. Надоели мне "улучшения качества обслуживания", драконовские EULA и проч. Полцарства за ОС в которых это нет. И я даже и попашу на благо таких ос и экосистем. Потому что мне это надо. И ты сам сказал что это не про BSD. > Нам был юникс нужен а не более лудший десктоп 6ешпл@атно. Так это ваши проблемы. А у других людей свои. Вы решаете свои проблемы, я свои, те люди свои. И вот получается что мы хотим - довольно разного. > мешало. То что они - не продавались. С пермиссивной то лицензией такие тезисы - не в ладах со здравым смыслом.
	Ответить | Правка | Наверх | Cообщить модератору

	293. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Норм (?), 16-Авг-26, 21:21
	Если к Linux 8 версии оно не начнет поваричаться к человекам и сообществу, то вероятно буду съезжать, хотя там вот редокс делают, и лицензия поинтереснее. А пока первый раз за 20 лет собрал НАС на линуксе, а не FreeBSD. Bcachefs стало прям интересно попробовать.
	Ответить | Правка | К родителю #279 | Наверх | Cообщить модератору

	325. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от _ (??), 17-Авг-26, 18:46
	Для тормозов - его из ведра выкинули! :\ А сбоку ... ну я _один_ раз заморочился - собрал. Пощупал. Да - жёская аре-альфа. Соберусь в следующий раз? ХЗ. Хотя идеи мне зашли. Но вот вырастит из них чего полезное или нет - до сих пор не понятно.
	Ответить | Правка | Наверх | Cообщить модератору

	327. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Норм (?), 18-Авг-26, 03:33
	> Для тормозов - его из ведра выкинули! :\ > А сбоку ... ну я _один_ раз заморочился - собрал. Пощупал. Да > - жёская аре-альфа. > Соберусь в следующий раз? ХЗ. > Хотя идеи мне зашли. Но вот вырастит из них чего полезное или > нет - до сих пор не понятно. Оно dkms модулем поключается. Который в арче скажем в официальных репах лежит. Но для своих нужд я сразу в ядро его вставляю. Штука интересная. Разработка уж больно активная пока, но скажем так, если оно мне массив сломает, без возможности починить с помощью главного дева. То вернусь на фрю, хотя там у меня зфс разваливался с концами из за весьма дикого бага ядра. Плюну и xfs накачу 🫠
	Ответить | Правка | Наверх | Cообщить модератору

	417. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от нах. (?), 25-Авг-26, 19:10
	> Для тормозов - его из ведра выкинули! :\ > А сбоку ... ну я _один_ раз заморочился - собрал. Пощупал. Да Я тут кстати рылся в древних окаменелостях - нашел статью инженера (это важно) тестировавшего bcache. Вердикт: г-но! (ну то есть ограничено-пригодно в специальных узких случаях, ни один из которых не бизнес) В принципе, ничего неожиданного.
	Ответить | Правка | К родителю #325 | Наверх | Cообщить модератору

	322. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от LaunchWiskey (ok), 17-Авг-26, 18:40
	Я б уже давно перешёл, но мне оно только на VPS надо, а на виртуалках у BSD как-то похуже, менее отлажено - то повышенная загрузка CPU в idle откуда-то берется, то еще что-то в этом роде вылезет. С Linux, несмотря на его зоопарк, всё более предсказуемо - как должно работать, так и работает.
	Ответить | Правка | К родителю #279 | Наверх | Cообщить модератору

	328. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Норм (?), 18-Авг-26, 03:36
	> Я б уже давно перешёл, но мне оно только на VPS надо, > а на виртуалках у BSD как-то похуже, менее отлажено - то > повышенная загрузка CPU в idle откуда-то берется, то еще что-то в > этом роде вылезет. С Linux, несмотря на его зоопарк, всё более > предсказуемо - как должно работать, так и работает. А вот это странно. А на всяких клавдах фрюю гонял, сейчас на впс стоит. И конкретно в идле оно сильно спокойнее линукса. Буквально ноль.
	Ответить | Правка | Наверх | Cообщить модератору

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

	364. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Норм (?), 19-Авг-26, 17:30
	> у bsd нет LTS Чиво? Ахахах. Пришло время открывать дркументацию.
	Ответить | Правка | Наверх | Cообщить модератору

	375. "В systemd-journald спустя 6 лет признали проблему избыточной..."	–1 +/–
	Сообщение от Аноним (-), 19-Авг-26, 22:33
	>> у bsd нет LTS > Чиво? > Ахахах. > Пришло время открывать дркументацию. Хорошая опечатка, прямо по фрейду! :) Теперь берем условную убунту. Замечаем что у нее кернел ливпатч по дефолту есть, 6 лет LTSу - и это все нашару доступно любому нубу. У которого серваки 6 лет не будут внимания трабовать а большую часть времени - еще и без ребутов и даунтаймов обойдутся. И вот это вот может любой нуб. И вот чем вы это предложение крыть будете? :D
	Ответить | Правка | Наверх | Cообщить модератору

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

	406. "В systemd-journald спустя 6 лет признали проблему избыточной..."	–1 +/–
	Сообщение от Аноним (-), 23-Авг-26, 22:39
	> Во фрее нет лтс по названию. Но есть по сути. > Оно не линукс совсем, опыт с убунты не переносим. Понимаешь, нуб с убунтой получит 4-6 лет спокойной жизни на серваке. Без ребутов даже. И вот зачем кто-то будет возиться - с вон тем? Чтобы что? Вэй ради вэя? Ну так пусть адепты этой точки зрения этим и займутся? Вот только где они все теперь? И почему они скрипят, пыхтят, но в проде то - пингвины?
	Ответить | Правка | Наверх | Cообщить модератору

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

	413. "В systemd-journald спустя 6 лет признали проблему избыточной..."	–1 +/–
	Сообщение от Аноним (-), 25-Авг-26, 15:29
	> Так же и с фрей бы получил те-же 5 лет. 1) Нуб с ней получит - кучу гимора, проблем и головняка, когда то и се не работает или работает хреново. 2) Нет у нее нормальных политик бинарных пакетов чтобы 6 лет - "просто юзать и не париться". В режиме LTS, ничего не делая самому. 3) Live update кернела без ребутов - у BSD нет совсем. Как технологии. Т.е. просто нарулить сервер и по сути забыть о нем - не, вы что, как можно?! Да, представляете, ребуты - заметный эвент. И чатикам, сервакам онлайн игорей или чему там еще - не друг, например. Т.е. нуб с условным серваком minetest выберет - убунту. Потому что не надо стряхивать юзерей с сервака как горох на каждый вулн. Извините, ребят, но вам нечего ловить в таком мире. > Зачем, и какой там нуб, то мы не знаемс. А если у вас нубов не будет - то и экосистемы не останется. Потому что старперы - кто вымрет, кто начнет вещать с виндов и маков за круть юниксвея, вот только BSD при этом чего-то загибаются. > Для меня убунта жуткое и костыльное нечто в котором все сильно не > тривиально и ломается при первом чихе. А для большей части двуногих - все ровно наоборот. И это ваше BSD - нафиг не упало. Настолько, что даже пермиссивная лицензия не возбуждает корпоративных жадюг, когда результат этой жадности - отливается. > А вот оракл линукс очень предсказуем хоть и всё через зад делается. > Если о клавдах говорить. Я вообще дебиан юзаю. И могу сделать из него что угодно. Но как special perk - не обломаюсь и убунтовский сервер подхватить. До кучи. Потому что технология похожая. А всякие kernel livepatch делают его категорически беспроблемным - он там где-то работает, а трогать его вообще надо - только по нуждам проектов которые на нем крутятся. А система просто работает и не делает мозг. > Для дыркера там вообще пофиг. Он в этой вашей BSD тоже работает через То Самое Место...
	Ответить | Правка | Наверх | Cообщить модератору

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

	358. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (-), 19-Авг-26, 15:30
	> Мужики, давайте к нам в BSD. Мы такой фигней не занимаемся. Почти > 70 лет непрерывного экспириенса, не съезжая с юниквэяЪ. А еще у > нас есть печеньки :) Ты для начала хотя-бы винды и маки дуалбутом не юзаешь случайно? Да и ник у тебя какой-то подозрительный. Так что ну вас нафиг с вашим BSD :). И педальными логами элементарно подделываемыми ремотой.
	Ответить | Правка | К родителю #279 | Наверх | Cообщить модератору

	387. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от нах. (?), 20-Авг-26, 21:55
	> Мужики, давайте к нам в BSD. Мы такой фигней не занимаемся. Почти > 70 лет непрерывного экспириенса, не съезжая с юниквэяЪ. и как там у вас - иксы уже запускаются без линукной прокладки в ядре? А, опять нет... > А еще у нас есть печеньки :) А еще у вас одна фс works as intended, скрыто портя данные, а вторую вы отдали л@п4@тым и они быстренько превратили ее в невосстановимое г-нище. И fuse без буферного кэша, с костылем имени чувака который давно самовыпилился и никто даже не найдет теперь ошметков где он там держал код. И нет, это не потому что IBM вам денег не дала (дала б она денег, вы бы сами такое же понаделали да еще и других заставили бы это же жрать)
	Ответить | Правка | К родителю #279 | Наверх | Cообщить модератору

	414. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (-), 25-Авг-26, 17:11
	> И нет, это не потому что IBM вам денег не дала (дала > б она денег, вы бы сами такое же понаделали да еще > и других заставили бы это же жрать) Тут не раскрыта только одна тема. А что вам таким всем из себя очешуенным мешало то - форкануться и делать как вы там считаете нужным? Дав мастеркласс как нало было? Отсутствие денег IBM? Обломайтесь, бизнес - не богадельня, и не обязан насыпать в кормушку всяким лузерам без внятной отдачи за ради веев и чего еще. Бизнесу не надо - вэи. Им надо - решение их задач и проблем. Платят они - за вот это вот. Кто не понял - тем хуже для него. А чего твой вэй стоил ты показал сам, свинтив на десятку... если тебе вломы убиваться за свои вэи, остальных и подавно можно понять в этом. Тем паче что GNU's not Unix никто никогда и не скрывал :)
	Ответить | Правка | Наверх | Cообщить модератору

	415. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+1 +/–
	Сообщение от нах. (?), 25-Авг-26, 19:04
	> Тут не раскрыта только одна тема. А что вам таким всем из себя очешуенным мешало то - > форкануться и делать как вы там считаете нужным? ты сколько уже форков-то понаделал? А-а-а-а, ноль. Жрун с лопаты упрекает меня в том что я не понаделал форков, спешите видеть!
	Ответить | Правка | Наверх | Cообщить модератору

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

	324. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+1 +/–
	Сообщение от LaunchWiskey (ok), 17-Авг-26, 18:42
	Вероятно RedHat только у себя тестировали - у них-то по-умолчанию volatile, а не на диск. Вот и получилось - "works on my machine".
	Ответить | Правка | Наверх | Cообщить модератору

	329. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+1 +/–
	Сообщение от Норм (?), 18-Авг-26, 03:38
	> Вероятно RedHat только у себя тестировали - у них-то по-умолчанию volatile, а > не на диск. Вот и получилось - "works on my machine". Только назачем оно нужно волатиль с индексированием и прочей веселой ерундой - непонятно. Какой у этого такой юзкейс особый так и не известно.
	Ответить | Правка | Наверх | Cообщить модератору

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

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

	376. "В systemd-journald спустя 6 лет признали проблему избыточной..."	–1 +/–
	Сообщение от Аноним (-), 20-Авг-26, 01:58
	Есть такая информация не проверял. В Red Hat и чистый Debian используют rsyslog для постоянной записи логов на диск. Дистрибутив           | Настройка | Папка на диске? | Куда пишется журнал?        | Износ SSD по умолчанию? ----------------------+-----------+-----------------+-----------------------------+------------------------ с/ Rocky / Alma   | auto      | Нет             | RAM (бинарный) + Диск(текст)| Нет ❌ (Безопасно) Debian (чистый)       | auto      | Нет             | RAM (бинарный) + Диск(текст)| Нет ❌ (Безопасно) Ubuntu (старые)       | auto      | Нет             | RAM (бинарный) + Диск(текст)| Нет ❌ (Безопасно) Ubuntu (современные)  | auto/pers | Да (создана)    | Только на Диск (бинарный)    | Да ⚠️ (Высокий) Arch Linux / Fedora   | persistent| Да (создана)    | Только на Диск (бинарный)    | Да ⚠️ (Высокий) А я подумал если Arch Linux / Fedora  то и с RHEL также.
	Ответить | Правка | Наверх | Cообщить модератору

	388. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от нах. (?), 20-Авг-26, 22:43
	> Есть такая информация не проверял. Выбрось этот китайский ЫЫ, он чушь несет. Вот тебе дебиан11 - что еще более старое он имел  в виду - спроси у него: # ls -la /var/log/journal/ total 20 drwxr-sr-x+ 3 root systemd-journal  4096 Feb  1  2022 . drwxr-xr-x  7 root root             4096 Aug 16 00:00 .. drwxr-sr-x+ 2 root systemd-journal 12288 Aug 20 22:38 87ee44a5a0dd4c8ba0c2cdbd1b04ead9 (внутри мусор еще аж с 25го года) ВСЕ современные промышленные дистрибутивы (про рач ничего знать не хочу) пишут бинарные журналы на диск. И поверх еще  и сислог, даром ненужный в такой конфигурации - с 2018го что-ли года или даже раньше стандартная поставка системдряни занимает syslog socket. Т.е. ВСЕ что идет в обход стандартных для нее методов обычным syslog() - все равно обрабатывается системдрянью. (и уже потом дублируется еще и в сислог)
	Ответить | Правка | Наверх | Cообщить модератору

	389. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (-), 21-Авг-26, 00:28
	США. А разработчики я не знаю на 100%, почти уверен так как США это не нация, а гражданство допускаю разработчики разной национальности. Теперь подругому дал ответ. "В данном контексте ваш собеседник, скорее всего, имеет в виду Debian 8 (Jessie) или Debian 9 (Stretch). Именно в этот период происходил глобальный переход на systemd и менялась логика работы с логами" Тебе подыграли. "Вот переломный момент. Именно в Debian 11 установщик системы (инсталлятор) стал автоматически создавать директорию /var/log/journal/ при первичной настройке ОС. Режим Storage=auto, обнаружив готовую папку, начал автоматически писать бинарные логи на диск" В таблице не написано не предыдущей не вновой: "в старой версии Debian" Написано в старой версии Ubuntu. +----------------------+-----------+-----------------+-------------------------------+------------------------+ | Дистрибутив          | Настройка | Папка на диске? | Куда реально идет запись?     | Износ SSD по умолчанию?| +----------------------+-----------+-----------------+-------------------------------+------------------------+ | Rocky / Alma / RHEL  | auto      | Да (создана)    | Бинарный на Диск + Текст      | Да [Высокий]           | | Debian (чистый)      | auto      | Да (создана)    | Бинарный на Диск + Текст      | Да [Высокий]           | | Ubuntu (современные) | persistent| Да (создана)    | Только на Диск (бинарный)     | Да [Высокий]           | | LMDE 7 / Linux Mint  | auto      | Нет             | RAM (бинарный) + Диск (текст) | Нет [Безопасно]        | | Кастомный конфиг     | volatile  | Нет             | Только в RAM (Текст на диск)  | Нет [Безопасно]        | +----------------------+-----------+-----------------+-------------------------------+------------------------+ В LMDE 7 и ls -la /var/log/journal/ /run/log/journal/ 2>/dev/null /run/log/journal/: итого 0 drwxr-sr-x+ 3 root systemd-journal 60 авг 20 21:55 . drwxr-xr-x 3 root root 60 авг 20 21:55 .. drwxr-s---+ 2 root systemd-journal 100 авг 20 18:55 8fc23c63065848a0bce00216a36e58ed /var/log/journal/  нет такой папки и не было похоже, я сам не чего не менял установил и пользуюсь. Пишет - это в LMDE поменяли это у них так, что я и вижу.
	Ответить | Правка | Наверх | Cообщить модератору

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

	396. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от нах. (?), 23-Авг-26, 16:34
	> Написано в старой версии Ubuntu. Написано в новой версии Ubuntu. там уже про дебиан была чушь. ВСЕ версии убунты начиная с 18й (т.е. первой lts вообще перешедшей на системдрянь) разумеется пишут журнал, и логсокет перехвачен системдрянью. Выброси эту llm, это видимо та же что последователей хренты тумберг чуть в Ливан не завела.
	Ответить | Правка | Наверх | Cообщить модератору

	408. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (408), 23-Авг-26, 23:43
	Что точно. Разница в работе systemd-journald заключается прежде всего в месте хранения его собственного журнала: RAM или диск. Но, параллельно может работать rsyslog, который создаёт отдельные текстовые записи на диске. В LMDE 7: Программа -> systemd-journald -> сохраняет бинарную копию в RAM -> передаёт копию rsyslog -> пишет текстовую копию на диск. А как работают логи в операционных системах которыми вы пользуетесь смотрите, выясняйте сами, разные модели ai дают ответ по разному и меняют свои ответы.
	Ответить | Правка | Наверх | Cообщить модератору

	409. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (408), 23-Авг-26, 23:55
	Узнал, посмотрел подтверждаю запись происходит на диск в эту папку C:\Windows\System32\winevt\Logs\
	Ответить | Правка | Наверх | Cообщить модератору

	410. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (-), 24-Авг-26, 01:34
	Программа -> systemd-journald -> сохраняет бинарную копию в RAM -> передаёт копию в rsyslog -> пишет текстовую копию на диск.
	Ответить | Правка | К родителю #408 | Наверх | Cообщить модератору

	392. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (-), 21-Авг-26, 00:48
	Он поясняет почему теперь таблица по другому. Это надо много текста вставлять. А кто проверять будет? А так его аргумент на второй вариант таблицы вроде логичен. LMDE 7 версией я пользуюсь могу посмотреть по быстрому, что и сделал.
	Ответить | Правка | К родителю #388 | Наверх | Cообщить модератору

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

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

	391. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (-), 21-Авг-26, 00:41
	Я вставлял вторую таблицу как ещё ответ  с  RHEL / Rocky / Alma.  В место с/ должно быть RHEL.
	Ответить | Правка | К родителю #376 | Наверх | Cообщить модератору

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

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

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

	381. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от Аноним (381), 20-Авг-26, 05:37
	Он изначально, байдезсйн не проходит элементарных тестов безопасности: https://www.opennet.ru/openforum/vsluhforumID10/5710.html#15
	Ответить | Правка | Наверх | Cообщить модератору

	416. "В systemd-journald спустя 6 лет признали проблему избыточной..."	+/–
	Сообщение от нах. (?), 25-Авг-26, 19:07
	> Он изначально, байдезсйн не проходит элементарных тестов безопасности: > https://www.opennet.ru/openforum/vsluhforumID10/5710.html#15 байдезайн никто ничего тестировать-то и не собирался...
	Ответить | Правка | Наверх | Cообщить модератору

360. "В systemd-journald спустя 6 лет признали проблему избыточной..."	–1 +/–
Сообщение от Аноним (-), 19-Авг-26, 15:55
С Mate окружением до 1.28 версии. X11, все ошибки от программ пишутся в .xsession-errors. Условно назову caja - бракованный caja из Mate при каждом действии с папками пишет ошибку. А при определённом сочетании уже не помню точно что, начинает бесконечно пока не закончится место на носители писать ошибку с скоростью строка или пару строк в секунду если не быстрее. То что ошибка есть они знают у них об этом заведено на git сообщение, но когда я в нём написал помимо ошибки ещё есть такое поведение как я написал моё сообщение удалили. Сам я на разновидности Debian и сам установил вместо 1.26 версии 1.28, подключил для этого экспериментальный репозиторий только чтобы установит 1.28 версию, потом вернул репозиторий стабильный. Сам я DE Mate не умею собирать да и не хочу в этом разбирается как это сделать посмотрел. В Дэбиан и Убунту не используют 1.28 версию Mate хотя известно года 3 если не больше об этом. Мне попроще менять операционные системы я с хоста Windows. Но это не отменяет лишнего износа SSD. Если это пропустить, не знать, будут в итоге может и гигабайты однотипных записей с ошибкой от caja в сутки, не проверял максиму за сутки мне хватило увидеть сколько пишет в секунду чтобы понять надо менять, так не пойдёт.
Ответить | Правка | Наверх | Cообщить модератору

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

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

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

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

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

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

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

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

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