forum.opennet.ru - "В systemd-journald спустя 6 лет признали проблему избыточной нагрузки на накопители" (82)

"В systemd-journald спустя 6 лет признали проблему избыточной нагрузки на накопители"

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

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

Оглавление

Всю жизнь монтирую var log в tmpfs кстати , Аноним (1), 00:23 , 15-Авг-26, (1)

Удачи потом в расследовании инцидентов , Аноним (2), 00:25 , 15-Авг-26, (2) +20

Можно подумать, что ты хоть раз расследовал на гигабайтах логов Есть смысл време, Аноним (15), 01:04 , 15-Авг-26, (15) +3

Гигабайты там и не нужны Хватает 100 строчек выхлопа тогоже ядра, чтобы понять,, Аноним (2), 01:21 , 15-Авг-26, (19) +3

Ничего не мешает убрать маунт при необходимости Хотя при паниках ядра в журнал , Аноним (1), 02:19 , 15-Авг-26, (34)
Но с tmpfs строчек будет зачастую 0 Почему-то , Аноним (-), 02:40 , 15-Авг-26, (41)

Может он эти инциденты и создает В расследовании главное не выйти на самого се, Аноним (16), 01:06 , 15-Авг-26, (16) +2
Каких еще инцидентов У нас таких нет, у нас все нормальные ребята , Аноним (1), 02:14 , 15-Авг-26, (33)
А с journald там тоже рулетка Во время инцидентов он теряет или повреждает свои, Аноним (76), 07:19 , 15-Авг-26, (76)
Прощще переустановить, чем мутить эти логи, раз в миллион лет может быть баг, в , Аноним (80), 08:23 , 15-Авг-26, (80)

Это все капля в море 700Mb логи 5Гб Браузер Поэтому держу браузер в psd profile, Аноним (80), 08:24 , 15-Авг-26, (81)

И года не прошло А хотя не, прошло 6 , Аноним (3), 00:35 , 15-Авг-26, (3) +2

А как пели бинарный формат, это не партянки, всё быстро , Аноним (6), 00:49 , 15-Авг-26, (6) +9

А оно и правда - быстро Скажем я могу более-менее в реальном времени парсить в, Аноним (16), 00:59 , 15-Авг-26, (12) –3

а зачем вам ssh в кровавом энткрпрайзе, он бай дизайн не предназначен для этого,, Аноним (30), 01:48 , 15-Авг-26, (30) +4

У меня нет тех ваших энтерпрайзов и я не переклинен на этих кейсах У энтерпрайз, Аноним (-), 02:33 , 15-Авг-26, (38) –1

Если ты в риалтайме парсишь гигзы логов от ssh Что-то ты неправильно делаешь , Аноним (6), 03:11 , 15-Авг-26, (44)
А теперь попробуй то же самое с cron-задачами Нет, -u crond и прочие вариации н, вымя (?), 03:47 , 15-Авг-26, (50)

Для вас придумали таймеры, Аноним (55), 04:14 , 15-Авг-26, (55)

которые в логе вообще не отсвечивают Вот где в журнале написано про запуск d, вымя (?), 06:21 , 15-Авг-26, (69)

Зато это хоть возможно будет сделать Вот рубанёт тебе питание, журнал окажется , freehck (ok), 04:13 , 15-Авг-26, (54)

Разворачивать кх или эластик ради пятка хостов возможно виртуалок как-то оверки, фняк. (?), 09:58 , 15-Авг-26, (94)

А я думал это норма, что что все эти лог журналы насилуют твой ссд, чтобы потом , Аноним (4), 00:35 , 15-Авг-26, (4) +5

Да не парься ты так - форенсики с твоего SSD и с якобы-in-place файлухи вынут ку, Аноним (-), 00:52 , 15-Авг-26, (8) +1

-o discard делает ровно это, Аноним (55), 04:20 , 15-Авг-26, (56)

В данном случае опеннетчики продемонстрировали типичный подход много критиканит, Аноним (-), 00:48 , 15-Авг-26, (5) +1

Так может лучше задействовать для бана ботов нормальную базу данных, а не эти ош, Аноним (9), 00:53 , 15-Авг-26, (9) +2

Ваша проблема в том что у вас в итоге только - Голый зад - и нифига кроме расска, Аноним (16), 01:03 , 15-Авг-26, (13)

Драмаквин в треде, развел соплей будто уже это отключилиДержи такой же настрой, , ыых (?), 08:57 , 15-Авг-26, (85)

Вся суть архитектуры системды , Аноним (6), 00:55 , 15-Авг-26, (10) +3

А альтернативы то какие Сидеть с голым задом или огроменные энтерпрайзные монст, Аноним (16), 01:17 , 15-Авг-26, (17) –4

А вы со своим тэйком про голые зады по всеё дискуссии растеклись по своей воле и, Аноним (-), 01:30 , 15-Авг-26, (23)

Я на лично своих серверах ботов баню за счет функциональности journald Использу, Аноним (-), 02:24 , 15-Авг-26, (37) –2

Вышли из кельи, протолкнули, и назад мейнтэйнить Благодать tail, не , Аноним (43), 02:45 , 15-Авг-26, (43)

Ты ему ещё расскажи, что текстовые логи, оказывается, можно ротировать, и поиск , freehck (ok), 04:44 , 15-Авг-26, (60)

Спроси у гугла, почему он в хромосе НЕ использует системду , Аноним (6), 03:17 , 15-Авг-26, (45)

Недавно столкнулся с чюдом Есть такая штука Agent DVR для ip камер, так вот при, arthi747 (ok), 07:36 , 15-Авг-26, (77)

оверЫнЖЫРнеринг , Аноним (26), 01:36 , 15-Авг-26, (26)
слепому ясно, но имя им _легион_ , dannyD (?), 06:48 , 15-Авг-26, (74)
Вообще в статье неправильно указано - игнорировался Это неправильное определе, ыых (?), 09:00 , 15-Авг-26, (87)

Ждём исправления в нашем любимом Дебиане лет через 6-8 , Rev (ok), 01:17 , 15-Авг-26, (18) –1

Хехе, не дождетесь Там только на профилирование, дебаг и рабочие фиксы уйдёт го, Аноним (20), 01:24 , 15-Авг-26, (20)

А 12309 никуда и не делся Достаточно попробовать попользоваться машиной с небол, Аноним (-), 01:33 , 15-Авг-26, (25)

Вот в этом и суть , Аноним (20), 01:59 , 15-Авг-26, (32)
Потом пойти в магазин и обнаружить что сраный китайский мобильник за 50 баксов -, Аноним (-), 02:36 , 15-Авг-26, (39) +1

Проблема то не решена, а у некоторых конкурентов таких архитектурных просчётов и, Аноним (43), 08:53 , 15-Авг-26, (84)

Ну что, теперь системда не будет тормозить на старых пк и одноплатниках , Аноним (21), 01:26 , 15-Авг-26, (21) +3
цифровая буржуазная демократия , хехе , Аноним (22), 01:29 , 15-Авг-26, (22)

Все демократично кто работу работает тот и решает что ему надо при этом было , Аноним (-), 02:37 , 15-Авг-26, (40) +2

Я вижу здесь корреляцию со слегка возросшей ценностью SSD, сейчас уже не так про, Аноним (24), 01:30 , 15-Авг-26, (24)

так они хуже всех насилуют диск, Аноним (26), 01:37 , 15-Авг-26, (27) +3

Может, всё-таки лучше всех , Аноним (6), 03:21 , 15-Авг-26, (46)

Какие , Аноним (28), 01:41 , 15-Авг-26, (28)
Примерно так же, уже много лет, многие ждут поддержку SHA256 Git репозиториев в , zionist (ok), 01:51 , 15-Авг-26, (31) +1
Ссылка , Аноним (35), 02:22 , 15-Авг-26, (35)

Да я не думаю что будет так строго, скорее всего всем причастным года 2 условно , Аноним (24), 02:43 , 15-Авг-26, (42) +3
Тут надо просить вышку, а то количество жертв среди SSD слишком велико , Аноним (6), 03:23 , 15-Авг-26, (47)

Многое говорит про качество подделки systemd, а ведь есть те, которые серьёзно с, Аноним (48), 03:40 , 15-Авг-26, (48) +3
ValdikSS это вроде с лора товарищ Насколько понимаю, разбирающийся не то что я, ryoken (ok), 03:43 , 15-Авг-26, (49) +1

На хабре, Аноним (62), 05:23 , 15-Авг-26, (62) +1
Если с Лора, значит он очень жёстко троллит , Аноним (64), 05:35 , 15-Авг-26, (64)
Да он такой - вздессущий , Аноним (64), 05:36 , 15-Авг-26, (65)
Легенда Кодек sbc-xq, обход замедления Ютуба это то чем он занимался , Xo (?), 09:37 , 15-Авг-26, (91)

Единого универсального алгоритма записи действительно не существует, потому что , Аноним (51), 04:06 , 15-Авг-26, (51)

Ой, и не говори даже Самое важное, на что ответа нет ну вот нахрена логам лока, freehck (ok), 04:59 , 15-Авг-26, (61) +1

Разработчики systemd-journald решили объединить текстовые логи в сложную бинарну, Аноним (51), 04:07 , 15-Авг-26, (52)
Всю дорогу пользуюсь syslog-ng Хватает аж за брови Плюс - вполне себе читаемые, iCat (ok), 04:11 , 15-Авг-26, (53)
Системда страшная помойка Число открытых багов измеряется тысячами Как и ожида, Норм (?), 04:40 , 15-Авг-26, (58) +2
То есть, знаменитое сообщество 8482 за шесть лет вместо исправления проблемы, Аноним (59), 04:41 , 15-Авг-26, (59) +1

Какой проблемы Разрабы системды проблемы не видели И конечно же ты сейчас внесе, ыых (?), 09:06 , 15-Авг-26, (90) +1

Изначальный отчет 2000 года закрыли потому, что Поттеринг попросил привести боле, Аноним (66), 05:51 , 15-Авг-26, (66) +1

Вот пример настоящей нейронки, которая защищает здесь проприетарные и полупропри, Аноним (48), 06:05 , 15-Авг-26, (67)

А где в том сообщении что-то сказано о защите каких-либо продуктов Там по-моему, Аноним (59), 07:06 , 15-Авг-26, (75)

Нейропомои в защиту здравого смысла , Аноним (43), 09:04 , 15-Авг-26, (89)

Ни хрена ты разрабов не знаешь Разрабы говорят только с теми людьми, кто их н, Аноним (86), 08:58 , 15-Авг-26, (86)

А влезая в issues тред с ноги, назвав всех дебилами и требуя быстро запилить не, llolik (ok), 09:55 , 15-Авг-26, (93)

Ждём того же, но уже у proxmox У них тоже база данных своя активно пишет на дис, Аноним (70), 06:28 , 15-Авг-26, (70)
Там Федора оказывается Просто увидел знакомые буквы в аптайм , Аноним (72), 06:34 , 15-Авг-26, (72)
А зачем вообще простому смертному юзеру логи , Аноним (82), 08:32 , 15-Авг-26, (82)
Спасибо ValdikSS Мегакрутой Специалист , Аноним (83), 08:41 , 15-Авг-26, (83)
Очередная новость от бёрди угадай автора по подаче , Аноним (88), 09:02 , 15-Авг-26, (88)
What a legend, Квас (?), 09:44 , 15-Авг-26, (92)

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

1. "В systemd-journald спустя 6 лет признали проблему избыточной..." +/–

Сообщение от Аноним (1), 15-Авг-26, 00:23

Всю жизнь монтирую /var/log в tmpfs кстати.

Ответить | Правка | Наверх | Cообщить модератору

2. "В systemd-journald спустя 6 лет признали проблему избыточной..." +20 +/–

Сообщение от Аноним (2), 15-Авг-26, 00:25

Удачи потом в расследовании инцидентов.

Ответить | Правка | Наверх | Cообщить модератору

15. "В systemd-journald спустя 6 лет признали проблему избыточной..." +3 +/–

Сообщение от Аноним (15), 15-Авг-26, 01:04

Можно подумать, что ты хоть раз расследовал на гигабайтах логов.
Есть смысл временно включать, чтобы проверить почему падает отдельная служба, но держать на постоянке и никогда туда не смотреть... ну ты сам себе буратино.

Ответить | Правка | Наверх | Cообщить модератору

19. "В systemd-journald спустя 6 лет признали проблему избыточной..." +3 +/–

Сообщение от Аноним (2), 15-Авг-26, 01:21

Гигабайты там и не нужны. Хватает 100 строчек выхлопа тогоже ядра, чтобы понять, почему вся система отъехала.
К слову, актуально даже на десктопе с теме же амдешными, кривыми GPU дровами.

Ответить | Правка | Наверх | Cообщить модератору

34. "В systemd-journald спустя 6 лет признали проблему избыточной..." +/–

Сообщение от Аноним (1), 15-Авг-26, 02:19

Ничего не мешает убрать маунт при необходимости. Хотя при паниках ядра в журнал все равно ничего не запишется.

Ответить | Правка | Наверх | Cообщить модератору

41. "В systemd-journald спустя 6 лет признали проблему избыточной..." +/–

Сообщение от Аноним (-), 15-Авг-26, 02:40

> Гигабайты там и не нужны. Хватает 100 строчек выхлопа тогоже ядра, чтобы
> понять, почему вся система отъехала.
Но с tmpfs строчек будет зачастую 0. Почему-то.

Ответить | Правка | К родителю #19 | Наверх | Cообщить модератору

16. "В systemd-journald спустя 6 лет признали проблему избыточной..." +2 +/–

Сообщение от Аноним (16), 15-Авг-26, 01:06

> Удачи потом в расследовании инцидентов.
Может он эти инциденты и создает? "В расследовании главное не выйти на самого себя!"

Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

33. "В systemd-journald спустя 6 лет признали проблему избыточной..." +/–

Сообщение от Аноним (1), 15-Авг-26, 02:14

Каких еще инцидентов? У нас таких нет, у нас все нормальные ребята.

Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

76. "В systemd-journald спустя 6 лет признали проблему избыточной..." +/–

Сообщение от Аноним (76), 15-Авг-26, 07:19

А с journald там тоже рулетка. Во время инцидентов он теряет или повреждает свои логи

Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

80. "В systemd-journald спустя 6 лет признали проблему избыточной..." +/–

Сообщение от Аноним (80), 15-Авг-26, 08:23

Прощще переустановить, чем мутить эти логи, раз в миллион лет может быть баг, в 99% случаев ты и не знаешь что это, это может быть баг самого ядра, или какого то софта завязанного на systemd.
Логи нужны разрабам. А то что вы разраб с opennet, сомневаюсь.

Ответить | Правка | К родителю #2 | Наверх | Cообщить модератору

81. "В systemd-journald спустя 6 лет признали проблему избыточной..." +/–

Сообщение от Аноним (80), 15-Авг-26, 08:24

>История тянется с марта 2020 года, когда в системе отслеживания ошибок был зарегистрирован отчёт, в котором было продемонстрировано, что генерирование около 500 КБ текстовых логов выливается в более чем 700 МБ физических операций записи на SSD. Разработчики systemd тогда наотрез отказались признавать проблему, ответили в стиле "вы не понимаете, как работают файловые системы", отказались от проведения профилирования и закрыли заявку с вердиктом "not actionable". Комментарии разработчиков собрали сотни отрицательных оценок от пользователей, однако позиция проекта осталась непреклонной.
Это все капля в море. 700Mb логи.
5Гб Браузер.
Поэтому держу браузер в psd profile-sync-daemon.

Ответить | Правка | К родителю #1 | Наверх | Cообщить модератору

3. "В systemd-journald спустя 6 лет признали проблему избыточной..." +2 +/–

Сообщение от Аноним (3), 15-Авг-26, 00:35

И года не прошло.. А хотя не, прошло) 6!

Ответить | Правка | Наверх | Cообщить модератору

6. "В systemd-journald спустя 6 лет признали проблему избыточной..." +9 +/–

Сообщение от Аноним (6), 15-Авг-26, 00:49

А как пели: бинарный формат, это не партянки, всё быстро...

Ответить | Правка | Наверх | Cообщить модератору

12. "В systemd-journald спустя 6 лет признали проблему избыточной..." –3 +/–

Сообщение от Аноним (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 лет признали проблему избыточной..." –1 +/–

Сообщение от Аноним (-), 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ообщить модератору

44. "В systemd-journald спустя 6 лет признали проблему избыточной..." +/–

Сообщение от Аноним (6), 15-Авг-26, 03:11

Если ты в риалтайме парсишь гигзы логов от ssh... Что-то ты неправильно делаешь.

Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

50. "В systemd-journald спустя 6 лет признали проблему избыточной..." +/–

Сообщение от вымя (?), 15-Авг-26, 03:47

> Скажем я могу более-менее в реальном времени парсить "все сообщения от sshd". Префильтр и индексированный доступ - обеспечит сам journald.
А теперь попробуй то же самое с cron-задачами. Нет, -u crond и прочие вариации не подходят, потому что красношляпые гении решили, что на каждый запуск задачи нужно плодить одноразовые session-c31337.scope. В итоге опять грепаем, только не из файла, а через, ээээ, пайпы. Очень удобно.

Ответить | Правка | К родителю #12 | Наверх | Cообщить модератору

55. "В systemd-journald спустя 6 лет признали проблему избыточной..." +/–

Сообщение от Аноним (55), 15-Авг-26, 04:14

Для вас придумали таймеры

Ответить | Правка | Наверх | Cообщить модератору

69. "В systemd-journald спустя 6 лет признали проблему избыточной..." +/–

Сообщение от вымя (?), 15-Авг-26, 06:21

...которые в логе вообще не отсвечивают. Вот где в журнале написано про запуск dnf-makecache.timer? А он запустился, вон, свежие следы в /var/cache лежат!
«Неудобно работать с логами? Просто выкиньте их!» Гениально.
В таймерах этих ещё и stdout/stderr без костылей не попадает ни в хвалёный journald, ни на почту. Свои-то файлы мне, может, и не жалко подпереть, но вот следить за миллионом дистрибутивных файлов для того, чтобы обставлять их override-ами, желания нет никакого.
Но вы, конечно, не прекращайте восхищаться гением Лёни, подарившему админам локалхостов многословный ароматизатор crontab, не идентичный натуральному.

Ответить | Правка | Наверх | 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ообщить модератору

4. "В systemd-journald спустя 6 лет признали проблему избыточной..." +5 +/–

Сообщение от Аноним (4), 15-Авг-26, 00:35

А я думал это норма, что что все эти лог журналы насилуют твой ссд, чтобы потом форензик экспертам было легче копаться в твоих штанах.

Ответить | Правка | Наверх | Cообщить модератору

8. "В systemd-journald спустя 6 лет признали проблему избыточной..." +1 +/–

Сообщение от Аноним (-), 15-Авг-26, 00:52

>  А я думал это норма, что что все эти лог журналы насилуют твой ссд,
> чтобы потом форензик экспертам было легче копаться в твоих штанах.
Да не парься ты так - форенсики с твоего SSD и с якобы-in-place файлухи вынут кучу данных с твоего SSD. Потому что флеш память не умеет in place перезаписи, внезапно. А стирание медленное и крупноблочное. Так что контроллер - всяко почти наверняка CoW сделает. И если читануть NAND напрямую без его услуг по пропуску лишнего...
Кстати, "secure" erase с явным протиранием нулями региона - тоже так не сработает. Оно протрет нолями ДРУГОЙ регион SSD. Вот явный запрос TRIM конкретного региона - еще может какую-то пользу принести. Только это блочный уровень, ФС сами по себе без явного прокостыливания такими вещами не оперируют.

Ответить | Правка | Наверх | Cообщить модератору

56. "В systemd-journald спустя 6 лет признали проблему избыточной..." +/–

Сообщение от Аноним (55), 15-Авг-26, 04:20

> ФС сами по себе без явного прокостыливания такими вещами не оперируют.
-o discard делает ровно это

Ответить | Правка | Наверх | Cообщить модератору

5. "В systemd-journald спустя 6 лет признали проблему избыточной..." +1 +/–

Сообщение от Аноним (-), 15-Авг-26, 00:48

> В данном случае разработчики systemd продемонстрировали
> типичный для корпоративного Open Source подход
В данном случае опеннетчики продемонстрировали типичный подход: много критиканить других и мало делать самим. А ваши текстовые логи - это прекрасно. Кроме того момента что даже просто банить околореалтаймно ботов по ним адское мучение. И либо дичайше жрет проц на парсинг гигабайтов - либо требует навороченных энтерпрайзных систем с индексами, и там вопрос амплификации, нагрузки и проч вообще - не раскрыт.
А каких-то реально сравнимых решений получить? Что вы, не дождетесь!

Ответить | Правка | Наверх | Cообщить модератору

9. "В systemd-journald спустя 6 лет признали проблему избыточной..." +2 +/–

Сообщение от Аноним (9), 15-Авг-26, 00:53

Так может лучше задействовать для бана ботов нормальную базу данных, а не эти ошмётки? А текстовые логи оставить только для отладки.

Ответить | Правка | Наверх | Cообщить модератору

13. "В systemd-journald спустя 6 лет признали проблему избыточной..." +/–

Сообщение от Аноним (16), 15-Авг-26, 01:03

> Так может лучше задействовать для бана ботов нормальную базу данных, а не эти ошмётки?
> А текстовые логи оставить только для отладки.
Ваша проблема в том что у вас в итоге только:
- Голый зад - и нифига кроме рассказов как все это "не надо".
- Невь...й enterprise grade которому для обслуги надо тиму фултайм админов в комплекте. Потому что ваша нормальная база данных - обслуживаемая. И надо - того кто умеет в DBA. Бесплатно работать DBA почему-то не любят.
А mid-range и просто возможность забанить надоевших ботиков с своего сервера без огромных напрягов и затрат? В вашей картине мира такое не предусмотрено вообще. А у поттера так можно было. И это причина по которой мир в целом предпочел - его. А вы можете свои базы данных админить, если вам это надо.

Ответить | Правка | Наверх | Cообщить модератору

85. "В systemd-journald спустя 6 лет признали проблему избыточной..." +/–

Сообщение от ыых (?), 15-Авг-26, 08:57

>  А у поттера так можно было.
Драмаквин в треде, развел соплей будто уже это отключили
Держи такой же настрой, пригодится когда и твою багу к системде закроют с "not a bug" и коротким каментом про "ты не понимаешь как работает компьютер"

Ответить | Правка | Наверх | Cообщить модератору

10. "В systemd-journald спустя 6 лет признали проблему избыточной..." +3 +/–

Сообщение от Аноним (6), 15-Авг-26, 00:55

> типичный для корпоративного Open Source подход: критический недочёт в инфраструктурном компоненте игнорировался годами
Вся суть архитектуры системды.

Ответить | Правка | Наверх | Cообщить модератору

17. "В systemd-journald спустя 6 лет признали проблему избыточной..." –4 +/–

Сообщение от Аноним (16), 15-Авг-26, 01:17

>> типичный для корпоративного Open Source подход: критический недочёт в инфраструктурном
>> компоненте игнорировался годами
> Вся суть архитектуры системды.
А альтернативы то какие? Сидеть с голым задом или огроменные энтерпрайзные монстры? Тоже мне дузовные метания мадам грицацуевой.

Ответить | Правка | Наверх | Cообщить модератору

23. "В systemd-journald спустя 6 лет признали проблему избыточной..." +/–

Сообщение от Аноним (-), 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 лет признали проблему избыточной..." +/–

Сообщение от freehck (ok), 15-Авг-26, 04:44

>> хотим последние 10 сообщений
> tail, не?
Ты ему ещё расскажи, что текстовые логи, оказывается, можно ротировать, и поиск сводится к последовательному чтению одного маленького последнего файла =)
В то же время journald для той же самой процедуры:
- сначала зачитает хэш-таблицу из хедера файла журнала и распарсит её
- затем произведёт по ней поиск, найдя все смещения нужных записей
далее, ДЛЯ КАЖДОЙ записи:
- сделает seek в нужное место heap-а по найденному смещению
- вычитает по смещению запись
- распарсит запись
- и только потом выведет её текстовую часть на экран
И если в случае с текстовым логом все эти потоки просто копируются по максимальному размеру буфера, то в случае с journald — оно перекладывается по одной записи за раз, скачет туда-сюда, да ещё и на парсинг структуры каждой зачитанной записи тратит время. =)
С верующими адептами Поттеринга — спорить мало смысла.
Они ж такие не от высокой экспертизы... =)

Ответить | Правка | Наверх | Cообщить модератору

45. "В systemd-journald спустя 6 лет признали проблему избыточной..." +/–

Сообщение от Аноним (6), 15-Авг-26, 03:17

> А альтернативы то какие?
Спроси у гугла, почему он в хромосе НЕ использует системду.

Ответить | Правка | К родителю #17 | Наверх | Cообщить модератору

77. "В systemd-journald спустя 6 лет признали проблему избыточной..." +/–

Сообщение от arthi747 (ok), 15-Авг-26, 07:36

Недавно столкнулся с чюдом. Есть такая штука Agent DVR для ip камер, так вот при запуске через systemd она жрет почти в два раза больше чем при запуске из архива.

Ответить | Правка | Наверх | 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 лет признали проблему избыточной..." +1 +/–

Сообщение от Аноним (-), 15-Авг-26, 02:36

> А 12309 никуда и не делся. Достаточно попробовать попользоваться машиной с небольшим
> объёмом озу, жёстким диском и большим количеством устройств на одной линии
> PCI.
Потом пойти в магазин и обнаружить что сраный китайский мобильник за 50 баксов - работает намного лучше чем весь этот античный кластерфак...

Ответить | Правка | К родителю #25 | Наверх | Cообщить модератору

84. "В systemd-journald спустя 6 лет признали проблему избыточной..." +/–

Сообщение от Аноним (43), 15-Авг-26, 08:53

Проблема то не решена, а у некоторых конкурентов таких архитектурных просчётов и вовсе не было.

Ответить | Правка | Наверх | Cообщить модератору

21. "В systemd-journald спустя 6 лет признали проблему избыточной..." +3 +/–

Сообщение от Аноним (21), 15-Авг-26, 01:26

Ну что, теперь системда не будет тормозить на старых пк и одноплатниках?

Ответить | Правка | Наверх | Cообщить модератору

22. "В systemd-journald спустя 6 лет признали проблему избыточной..." +/–

Сообщение от Аноним (22), 15-Авг-26, 01:29

> для корпоративного Open Source подход
цифровая "буржуазная демократия", хехе...

Ответить | Правка | Наверх | Cообщить модератору

40. "В systemd-journald спустя 6 лет признали проблему избыточной..." +2 +/–

Сообщение от Аноним (-), 15-Авг-26, 02:37

>> для корпоративного Open Source подход
> цифровая "буржуазная демократия", хехе...
Все демократично: кто работу работает тот и решает что ему надо при этом было :). А вот нытье на форумах и правда мало что решает. Особенно - технические проблемы.

Ответить | Правка | Наверх | Cообщить модератору

24. "В systemd-journald спустя 6 лет признали проблему избыточной..." +/–

Сообщение от Аноним (24), 15-Авг-26, 01:30

Я вижу здесь корреляцию со слегка возросшей ценностью SSD, сейчас уже не так просто "купить новый, а старый выкинуть". Людям стало не так легко расставаться с вещами. Надо теперь на браузеры переключаться и постить туда баги, там тоже конь не валялся.

Ответить | Правка | Наверх | Cообщить модератору

27. "В systemd-journald спустя 6 лет признали проблему избыточной..." +3 +/–

Сообщение от Аноним (26), 15-Авг-26, 01:37

> Надо теперь на браузеры
так они хуже всех насилуют диск

Ответить | Правка | Наверх | Cообщить модератору

46. "В systemd-journald спустя 6 лет признали проблему избыточной..." +/–

Сообщение от Аноним (6), 15-Авг-26, 03:21

Может, всё-таки лучше всех?

Ответить | Правка | Наверх | Cообщить модератору

28. "В systemd-journald спустя 6 лет признали проблему избыточной..." +/–

Сообщение от Аноним (28), 15-Авг-26, 01:41

> заявили исследовательские претензии
Какие?

Ответить | Правка | Наверх | Cообщить модератору

31. "В systemd-journald спустя 6 лет признали проблему избыточной..." +1 +/–

Сообщение от zionist (ok), 15-Авг-26, 01:51

Примерно так же, уже много лет, многие ждут поддержку SHA256 Git репозиториев в GitHub и в VS Code.

Ответить | Правка | Наверх | Cообщить модератору

35. "В systemd-journald спустя 6 лет признали проблему избыточной..." +/–

Сообщение от Аноним (35), 15-Авг-26, 02:22

> мейнтейнеры проекта изменили риторику и начали работу над оптимизацией механизмов сброса кэша и структуры хранения индексов journald
Ссылка?

Ответить | Правка | Наверх | Cообщить модератору

42. "В systemd-journald спустя 6 лет признали проблему избыточной..." +3 +/–

Сообщение от Аноним (24), 15-Авг-26, 02:43

> Ссылка?
Да я не думаю что будет так строго, скорее всего всем причастным года 2 условно дадут и обяжут таки пофиксить это недоразумение

Ответить | Правка | Наверх | Cообщить модератору

47. "В systemd-journald спустя 6 лет признали проблему избыточной..." +/–

Сообщение от Аноним (6), 15-Авг-26, 03:23

> Ссылка?
Тут надо просить вышку, а то количество жертв среди SSD слишком велико.

Ответить | Правка | К родителю #35 | Наверх | Cообщить модератору

48. "В systemd-journald спустя 6 лет признали проблему избыточной..." +3 +/–

Сообщение от Аноним (48), 15-Авг-26, 03:40

Многое говорит про качество подделки systemd, а ведь есть те, которые серьёзно считают, что systemd пример качественного софта. Благо все больше дистрибутивов отказываются от этого переусложненного и некачественного комбайна.

Ответить | Правка | Наверх | Cообщить модератору

49. "В systemd-journald спустя 6 лет признали проблему избыточной..." +1 +/–

Сообщение от ryoken (ok), 15-Авг-26, 03:43

ValdikSS это вроде с лора товарищ? Насколько понимаю, разбирающийся (не то что я). Где-то еще попадались его писания, не упомню.

Ответить | Правка | Наверх | Cообщить модератору

62. "В systemd-journald спустя 6 лет признали проблему избыточной..." +1 +/–

Сообщение от Аноним (62), 15-Авг-26, 05:23

На хабре

Ответить | Правка | Наверх | Cообщить модератору

64. "В systemd-journald спустя 6 лет признали проблему избыточной..." +/–

Сообщение от Аноним (64), 15-Авг-26, 05:35

>"ValdikSS это вроде с лора товарищ"
Если с Лора, значит он очень жёстко троллит.

Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

65. "В systemd-journald спустя 6 лет признали проблему избыточной..." +/–

Сообщение от Аноним (64), 15-Авг-26, 05:36

>"Где-то еще попадались его писания"
Да он такой - вздессущий!

Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

91. "В systemd-journald спустя 6 лет признали проблему избыточной..." +/–

Сообщение от Xo (?), 15-Авг-26, 09:37

Легенда. Кодек sbc-xq, обход замедления Ютуба это то чем он занимался.

Ответить | Правка | К родителю #49 | Наверх | Cообщить модератору

51. "В systemd-journald спустя 6 лет признали проблему избыточной..." +/–

Сообщение от Аноним (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 лет признали проблему избыточной..." +1 +/–

Сообщение от freehck (ok), 15-Авг-26, 04:59

Ой, и не говори даже. Самое важное, на что ответа нет: ну вот нахрена логам локалхоста этот долбаный индекс вообще? Для домашней системы и текстовый нормально сойдёт, а для энтерпрайза мы один фиг Elastic или Loki заюзаем.
Но это ещё что... Как на счёт такого аргумента: даже если нам вдруг зачем-то нужен индекс... Почему не оставить лог текстовым, как он есть, а индекс — хранить в отдельном файле РЯДОМ с логом? Это, между прочим, сделало бы систему устойчивой к повреждению индекса, и вообще все вопросы с journald сняло бы: все бы Поттерингу только спасибо сказали.
В общем, действительно не понятно, зачем journald нужен, и для кого он создавался. Он стоит на наших машинах исключительно потому, что он идёт в составе systemd-комбайна, который нам навязан в качестве промышленного стандарта.
И он, как выяснилось, все эти годы портил нам ssd-шки. Спасибо, Леннарт. Почему я не удивлён...

Ответить | Правка | Наверх | Cообщить модератору

52. "В systemd-journald спустя 6 лет признали проблему избыточной..." +/–

Сообщение от Аноним (51), 15-Авг-26, 04:07

Разработчики systemd-journald решили объединить текстовые логи в сложную бинарную структуру (чтобы по логам можно было делать быстрый поиск и индексацию) и выбрали для работы с ней mmap.В итоге получился худший архитектурный гибрид: структура данных сложная как у базы данных, но вместо механизмов СУБД (свой кэш, O_DIRECT, WAL) разработчики полностью доверились автоматике mmap. Когда в Linux изменилась логика работы контейнеров (cgroups), автоматика ядра начала бесконечно гонять эти 4 КБ страницы туда-обратно, уничтожая SSD.

Ответить | Правка | Наверх | Cообщить модератору

53. "В systemd-journald спустя 6 лет признали проблему избыточной..." +/–

Сообщение от iCat (ok), 15-Авг-26, 04:11

Всю дорогу пользуюсь syslog-ng.
Хватает "аж за брови".
Плюс - вполне себе читаемые логи.
Ну как-то странно нагружать логгер ещё и задачами базы данных, криптования и т.п.

Ответить | Правка | Наверх | Cообщить модератору

58. "В systemd-journald спустя 6 лет признали проблему избыточной..." +2 +/–

Сообщение от Норм (?), 15-Авг-26, 04:40

Системда страшная помойка. Число открытых багов измеряется тысячами. Как и ожидающих пулл реквестов.
Но они считают очень важным мержить верификавию возраста.
Контроль над репой поделён буквально между одним редхат и одним МС работником.

Ответить | Правка | Наверх | Cообщить модератору

59. "В systemd-journald спустя 6 лет признали проблему избыточной..." +1 +/–

Сообщение от Аноним (59), 15-Авг-26, 04:41

> История тянется с марта 2020 года
> разработчики systemd продемонстрировали типичный для корпоративного Open Source подход: критический недочёт в инфраструктурном компоненте игнорировался годами, пока ущерб репутации проекта в сообществе не превысил издержки на его исправление.
То есть, знаменитое "сообщество™" за шесть лет вместо исправления проблемы просто продолжало за обе щеки потреблять продукт "корпоративного подхода" - и теперь вы всерьез рассказываете о "репутации проекта" внутри этой группы дармоедов-халявщиков?

Ответить | Правка | Наверх | Cообщить модератору

90. "В systemd-journald спустя 6 лет признали проблему избыточной..." +1 +/–

Сообщение от ыых (?), 15-Авг-26, 09:06

> То есть, знаменитое "сообщество™" за шесть лет вместо исправления проблемы
Какой проблемы? Разрабы системды проблемы не видели.
> просто продолжало за обе щеки потреблять продукт "корпоративного подхода"
И конечно же ты сейчас внесешь выкладки использования дистрибутивов, включая вариации с замещением журналды на нормальный логгер, в домашнем и корпоративном использовании, за период этих 6 лет

Ответить | Правка | Наверх | Cообщить модератору

66. "В systemd-journald спустя 6 лет признали проблему избыточной..." +1 +/–

Сообщение от Аноним (66), 15-Авг-26, 05:51

> разработчики systemd продемонстрировали типичный для корпоративного Open Source подход: критический недочёт в инфраструктурном компоненте игнорировался годами, пока ущерб репутации проекта в сообществе не превысил издержки на его исправление.
Изначальный отчет 2000 года закрыли потому, что Поттеринг попросил привести более подробные данные для подтверждения проблемы.
Теперь отчет приняли БУКВАЛЬНО потому, что через 6 лет один конкретный человек эти данные наконец-то привел.
А новостник тем временем решил напеть о том, что причина на самом деле в каком-то "ущербе репутации в сообществе" да еще и с высоты своего дивана сразу оценил "издержки на его исправление". 🤦
Автор, ты извини, но на то самое пресловутое "сообщество" разработчикам было справедливо наплевать что в 2000 году, что сейчас - разрабы всегда говорят с теми конкретными людьми, кто реально вносит клад и говорит по делу. Поэтому когда в следующий раз захочешь приписать этой группе дармоедов какие-то победы над "корпоративным Open Source" - попробуй постараться сильнее: больше драмы, больше эмоций, больше раздувания слонов из мух, больше ничем не подтвержденных громких заявлений.

Ответить | Правка | Наверх | Cообщить модератору

67. "В systemd-journald спустя 6 лет признали проблему избыточной..." +/–

Сообщение от Аноним (48), 15-Авг-26, 06:05

Вот пример настоящей нейронки, которая защищает здесь проприетарные и полупроприетарные продукты. Как с галюцинировала про 2000 год, так дальше в тексте и пишет, хотя в следующем предложении правильно пишет про паузу в 6 лет.

Ответить | Правка | Наверх | Cообщить модератору

75. "В systemd-journald спустя 6 лет признали проблему избыточной..." +/–

Сообщение от Аноним (59), 15-Авг-26, 07:06

> Вот пример настоящей нейронки, которая защищает здесь проприетарные и полупроприетарные продукты.
А где в том сообщении что-то сказано о защите каких-либо продуктов? Там по-моему в защиту здравого смысла и против подачи новостей в стиле бульварных помоев.

Ответить | Правка | Наверх | Cообщить модератору

89. "В systemd-journald спустя 6 лет признали проблему избыточной..." +/–

Сообщение от Аноним (43), 15-Авг-26, 09:04

Нейропомои в защиту здравого смысла.

Ответить | Правка | Наверх | Cообщить модератору

86. "В systemd-journald спустя 6 лет признали проблему избыточной..." +/–

Сообщение от Аноним (86), 15-Авг-26, 08:58

>разрабы всегда говорят с теми конкретными людьми, кто реально вносит клад и говорит по делу
Ни хрена ты разрабов не знаешь. Разрабы говорят *только* с теми людьми, кто их не критикует (они же "высшая каста"!) Попробуй укажи им даже на очевидный их ляп, в ответ получишь море дерьма, не зависимо от того вносишь ты вклад или критикуешь "по делу".
Кстати, эта новость прекрасная этому иллюстрация.

Ответить | Правка | К родителю #66 | Наверх | Cообщить модератору

93. "В systemd-journald спустя 6 лет признали проблему избыточной..." +/–

Сообщение от llolik (ok), 15-Авг-26, 09:55

А влезая в issues тред с ноги, назвав всех дебилами и требуя быстро запилить "не знаю что, но как я сказал" (в общем типичный стиль от "анонимного сообчества") ты ожидаешь какой-то другой реакции, кроме GTFO ?
Вобщем-то, сам посмотри тред в issues: типичный стандартный birdie-тупняк, пока в другом тикете ValdikSS собственно и не протестировал нормально.

Ответить | Правка | Наверх | 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 лет признали проблему избыточной..." +/–

Сообщение от Аноним (82), 15-Авг-26, 08:32

А зачем вообще простому смертному юзеру логи?

Ответить | Правка | Наверх | Cообщить модератору

83. "В systemd-journald спустя 6 лет признали проблему избыточной..." +/–

Сообщение от Аноним (83), 15-Авг-26, 08:41

Спасибо ValdikSS! Мегакрутой Специалист!

Ответить | Правка | Наверх | Cообщить модератору

88. "В systemd-journald спустя 6 лет признали проблему избыточной..." +/–

Сообщение от Аноним (88), 15-Авг-26, 09:02

Очередная новость от бёрди: угадай автора по подаче.

Ответить | Правка | Наверх | Cообщить модератору

92. "В systemd-journald спустя 6 лет признали проблему избыточной..." +/–

Сообщение от Квас (?), 15-Авг-26, 09:44

> ValdikSS
What a legend

Ответить | Правка | Наверх | Cообщить модератору

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2026 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

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


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


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


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


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


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


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


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


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


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


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

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


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


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


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


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


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


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

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


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


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

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


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


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


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

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