Жжошь.

А что, jourlnald уже научился сгружать информацию «с момента
запуска компьютера»? Через astral_open(), не иначе.

Ну планируют научить. Логи будут брать из bios. UEFI как пробегала информация чтото такое позволяет.

Я не в курсе, что там и как с UEFI. Ну если так, то ничего не мешает.

«которые могут логировать целые транзакции, каждая размеров в несколько килобайт» в несколько сотен килобайт? по десятку раз в секунду...
текстовый лог все это успевает. а вот поттерподелие - дохнет.

man dmesg

man bootlogd

Ребят, если вам интересна новая технология, так читайте то, что пишут ее создатели.

Я уже замучался спамить ссылкой на перевод.

http://bb.comp-house.ru/comp-house.repo/wiki/TheJournal

Вот отдна из озвученых старых проблем журналирования:

Syslog это только одна из многих систем журналирования в локальных машинах. Отдельные логи содержатся для utmp/wtmp, lastlog, audit, kernel logs, firmware logs, а также есть большое количество специфичных для приложений журналов со своими форматами, что не только излишне сложно, но и скрывает связи между записями журналов в разных подсистемах.

А вот это уже нездоровые фантазии.

Что блин здесь нездорового-то? Ошибки возникают с момента включения компьютера и что странного в желании их логировать в общем журнале? Тем более, что биос умирает и на его место приходит вполне разумная среда с логом, которая ьерет на себя все больше и больше в плане инициализации и загрузки системы.

Я не в курсе, что там и как с UEFI. Ну если так, то ничего не мешает.

Мещает то, что в этот момент /var/log еще только на чтение. Поэтому и придумали универсальный механизм - стартуем с временным журналом в /run, а затем переходим в /var/log, когда он станет доступен на запись. Возможно, никогда, тгда так и будем жить в /run. А возможно, почти сразу, тогда в /run будет маленький кусочек. Но в любом случае он будет.

Мещает то, что в этот момент /var/log еще только на чтение. Поэтому и придумали универсальный механизм - стартуем с временным журналом в /run, а затем переходим в /var/log, когда он станет доступен на запись. Возможно, никогда, тгда так и будем жить в /run. А возможно, почти сразу, тогда в /run будет маленький кусочек. Но в любом случае он будет.

journald тебе для этого не нужен.

Syslog это только одна из многих систем журналирования в локальных машинах. Отдельные логи содержатся для utmp/wtmp, lastlog, audit, kernel logs, firmware logs, а также есть большое количество специфичных для приложений журналов со своими форматами, что не только излишне сложно, но и скрывает связи между записями журналов в разных подсистемах.

Как это мило: задекларировав благую цель борьбы со сложностью, тут же напроектировать... пардон, не то слово выбрал... наговнякать — вот верное слово... Так вот, задекларировав благую цель борьбы со сложностью, тут же наговнякать монстра, полностью состоящего из проблем и избыточной сложности.

Спасибо, ребята, но мы уж лучше как-нибудь по старинке с utmp пожимём, чем с этим.

s/пожимём/поживём/

Спасибо, капитан. Что бы я делал без тебя! Вопрос в другом, а именно, зачем этот схрон нужен уже после того, как появился /var/log/journal. Постарайся поднапрячь свой ганглий и не капитанить больше.

наговнякать — вот верное слово...

Это уж точно — без слез смотреть на код невозможно.

journald тебе для этого не нужен.

а что нужно?

Спасибо, капитан. Что бы я делал без тебя! Вопрос в другом, а именно, зачем этот схрон нужен уже после того, как появился /var/log/journal.

Правильно поставленный вопрос - половина ответа. Ответ на твой вопрос - потому что когда этот схрон делали, /var/log/ еще не был доступен на запись, а просто так удалять логи, наверное, не самая мудрая мысль.

А что ж мешает переписать из /run/log в /var/log?

потому что когда этот схрон делали, /var/log/ еще не был доступен на запись, а просто так удалять логи, наверное, не самая мудрая мысль.

То есть, часть логов в /var/log, часть — в /run/log и journald их в /var/log автоматом не переносит?

Ответ на твой вопрос - потому что когда этот схрон делали, /var/log/ еще не был доступен на запись

Я же просил не капитанить. :D
До того момента, как стартует демон логирования, логи тоже пишутся, в ядерный схрон. Как-то обходятся. Зачем же здесь плодить лишние сущности?
Надеюсь, что это пока просто недоработка и поттерлог будет вылизываться и с точки зрения логики работы тоже, а не просто абы как лишь бы куда-нибудь ляпало.

То есть, часть логов в /var/log, часть — в /run/log и journald их в /var/log автоматом не переносит?

Нет, не переносит. Копирует в общий лог. В /run/log лежит кусок текущего лога с момента старта. В /var/log лежит полный лог, и то, что было в предыдущем сеансе (само собой) и с куском текущего начала работы. И пишется соответственно дальше всё в /var/log. Размер атавизма в /run/log уже не изменяется.

То есть, часть логов в /var/log, часть — в /run/log и journald их в /var/log автоматом не переносит?

ну, вообще говоря, это одна из фис журнала - способность работать с несколькими журналами, как с одним. Поэтому 100% необходимости в слиянии нет.

С другой стороны, перенос журнала, это вовсе не такая уж и очевидная в реализации вещь. Во первых, это потеря ценных секунд при загрузке. Во вторых, вопросы с дублированием имен и с учетом объемов. Что делать, если объем перенесеного журнала уже не соответствует задланным ограничениям?

Я думаю, эту операцию логично или делать отдельным сервисом в systemd или фоном потихоньку переносить средствами самого журнала.

До того момента, как стартует демон логирования, логи тоже пишутся, в ядерный схрон.

даже удивляет, что потребовался sylog. Логи ведь уже пишутся в ядерный схрон...

Как-то обходятся.

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

Пробежался по исходникам — действительно, ничего никуда не переносит, вроде какие-то заготовки есть, но разбираться в этом неоткомментированном говнокоде лениво.

ну, вообще говоря, это одна из фис журнала - способность работать с несколькими журналами, как с одним. Поэтому 100% необходимости в слиянии нет.

Угу, после ребута в /run/log ничего нет, пролюбили логи, шикарно.

А хотят не обходиться, а сделать универсальный механизм журналирования, заменяющий все до_syslog костыли.

Давайте стартовать журнал до ядра, ок? А еще лучше до включения компьютера, ага.

даже удивляет, что потребовался sylog.

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

Логи ведь уже пишутся в ядерный схрон...

Как ты думаешь, почему в логах на диске оказываются все логи с момента старта ядра? Ядро в тот момент про железо даже не в курсе.

А хотят не обходиться, а сделать универсальный механизм журналирования, заменяющий все до_syslog костыли.

Эк тебя опять не в ту оперу понесло. Мне как-то всё-равно, чем будет логироваться, костылями, или универсальным механизмом журналирования. Главное, чтобы работало. Мне интересно нафейхоа держать рудимент в tmpfs после того, как его содержимое перенесено на диск. Нечего сказать, не юли уж тогда. Про некую неправильность удаления рудимента я тебя понял. Если больше версий никаких, то оставим никчёмный разговор.

Я думаю, эту операцию логично или делать отдельным сервисом в systemd или фоном потихоньку переносить средствами самого журнала.

Посмотри выше, я дал размер рудимента в tmpfs. Что там переносить? Какие ещё секунды при загрузке? Чем настолько эффективным ты упоролся с утра?

это одна из фис журнала - способность работать с несколькими журналами, как с одним. Поэтому 100% необходимости в слиянии нет.

Содержимое tmpfs переносится на диск и дальше в tmpfs ничего не пишется. В отличие от тебя, я хотя бы вижу это всё своими глазами, потому что использую systemd и именно v38.

Пробежался по исходникам — действительно, ничего никуда не переносит

Как-то ты плохо пробежался. После старта системы с чистым /var/log/journal его содержимое было в точности равно /run/log/journal. Первым делом туда посмотрел. Потом размер /var/log/journal/0940ae33b4e5d3a7315ede0600000014/system.journal начал расти.
Сейчас там вот такая оказия:
ls -l /var/log/journal/0940ae33b4e5d3a7315ede0600000014
итого 347344
-rw-r----- 1 root root 16777216 Янв 14 12:30 system@64575e99e0954cd7ba3b0dd46f8de3ab-00000000001bbfec-0004b678cadb89a4.journal
-rw-r----- 1 root root 71729152 Янв 14 19:06 system@64575e99e0954cd7ba3b0dd46f8de3ab-00000000001d0d1e-0004b67e54a372a3.journal
-rw-r----- 1 root root 71725056 Янв 14 22:58 system@64575e99e0954cd7ba3b0dd46f8de3ab-00000000001e5a50-0004b68190ac549f.journal
-rw-r----- 1 root root 71692288 Янв 15 11:40 system@64575e99e0954cd7ba3b0dd46f8de3ab-00000000001fa789-0004b68c359a3afb.journal
-rw-r----- 1 root root 67371008 Янв 15 12:24 system@64575e99e0954cd7ba3b0dd46f8de3ab-0000000000214c7b-0004b68cd3c08f97.journal
-rw-r----- 1 root root 56279040 Янв 15 12:53 system.journal
-rw-r-----+ 1 root root 69632 Янв 14 10:35 user-1000.journal

Рудимент как был стабильного размера после ребутов, так и остался.
ls -l /run/log/journal/0940ae33b4e5d3a7315ede0600000014
итого 632
-rw-r----- 1 root root 647168 Янв 14 06:36 system.journal

Содержимое tmpfs переносится на диск и дальше в tmpfs ничего не пишется. В отличие от тебя, я хотя бы вижу это всё своими глазами, потому что использую systemd и именно v38.

Таки он их мержит, странно, в коде не увидел, ну да ладно, не особо-то и смотрел. Тогда непонятно зачем он оставляет огрызки в /run/log...

Нда... И нахрена мне это всё было бы в tmpfs?
Мне конечно может и не жалко 353МБ из 8ГБ но, оно и на диске-то не особо нужно. Что он туда пишет, растудыт его налево.

du -s /var/log/journal
353052 /var/log/journal

Давайте стартовать журнал до ядра, ок? А еще лучше до включения компьютера, ага.

Было бы здорово. Часы же работают еще до включения компа.

Например, отлаживать включение от сети или клавиатуры было бы очень полезно. Или проблемы с просыпанием...

lsof /run/log/journal/0940ae33b4e5d3a7315ede0600000014/system.journal
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
systemd-j 1223 root mem REG 0,17 647168 10248 /run/log/journal/0940ae33b4e5d3a7315ede0600000014/system.journal
systemd-j 1223 root 14r REG 0,17 647168 10248 /run/log/journal/0940ae33b4e5d3a7315ede0600000014/system.journal

Да фиг его знает. Зачем-то ему нужно. Вцепился и не отпускает. Может думает, что /var/log отвалится, или в ro уйдёт. Может на случай буферизации при логировании через сетку. Дальше видно будет, какой полёт мысли будет у авторов и как будет дальше поттерлог развиваться.

353МБ

Интересно, сколько при этом занимают текстовые логи?

Мне конечно может и не жалко 353МБ

да это же пинцет. что он там набрал на 353МБ?

du -s /var/log/journal

353052 /var/log/journal

пожалуйста, проверь еще разик.

du -sh /var/log/journal/*

Как ты думаешь, почему в логах на диске оказываются все логи с момента старта ядра? Ядро в тот момент про железо даже не в курсе.

Вот из за этого в systemd накрутили дополнительные сервисы, чтобы собирать логи на ранней стадии. Логи ядра, это еще не все.

Содержимое tmpfs переносится на диск

значит, самое сложное сделали

и дальше в tmpfs ничего не пишется.

Логично. Видишь, и это реализовали.

В отличие от тебя, я хотя бы вижу это всё своими глазами, потому что использую systemd и именно v38.

Вот и интересует, что уже сделано. Анлинк старого журнала, стало быть остался. Это же ерунда. Небось, в дебаговых целях отключили...

du -sh /var/log/journal/*
476M /var/log/journal/0940ae33b4e5d3a7315ede0600000014

ЛДАП! Что-то у меня усиленно логирует. :D Надо разобраться. Уж не выхлоп ли emerge. :D

Вот и интересует, что уже сделано.

Если что ещё показать, спрашивайте. Мне тоже интересно, что сделано и что будет сделано. Просто есть некоторые вопросы, на которые у меня нет ответов. В код можно посмотреть, но это то, что есть по факту. Какие идеи у авторов это уже неизвестно, но очень любопытно.

Логи ядра, это еще не все.

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

Все текстовые логи в /var/log сейчас примерно мегабайт 200. Поттерлог за пару суток их уделал.

du -sh /var/log/journal/*
486M /var/log/journal/0940ae33b4e5d3a7315ede0600000014

Нашёл виновника. pptp-клиент взбесился.

Нашёл второго виновника. Подключенная флешка с fat32.

А сколько килобайт в /run/journal лежит?

то, что в /var/log может быть много записей, это понятно.

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

и еще, получается, что в /var/log лежит один файл с идиотским названием в стиле uuid. А обещали по файлу на каждый сервис с нормальными именами типа ntpd.journal, system.journal etc.

Этого тоже нет?

А сколько килобайт в /run/log/journal лежит?

680 КБ
Думаю, что на каждой системе будет разный размер, но порядок примерно такой.

А если там 300мбайт, то непонятно, откуда? Как он мог их набрать с момента старта до момента подключения корня?

Это за двое суток. Точнее за сутки. Если ещё точнее, то за пару часов. Виновников я нашёл.

в /var/log лежит один файл с идиотским названием в стиле uuid.

Каталог с этим самым названием. В каталоге файл system.journal и после ротации тоже название длинное.

А обещали по файлу на каждый сервис с нормальными именами типа ntpd.journal, system.journal etc.

Этого нет. Возможно надо как-то настройки покрутить (какие?). Возможно пока ещё не реализовано.

Релиз systemd v38 c поддержкой Journal, замены системе syslog

Windows-way рулит. Init, cron, mount/fstab, dbus, acpid, hostname, locale, readahead, sysctl, fsck и gnome-session уже интегрированы. Ждем релиз systemd с интегрированным вейландом. Тогда линуксу точно придет капец.

> Например, мне надо составить отчет по данным за день. Данных за день 100 гигабайт. Отчет строится только по определенным записям в логах. Индексация здесь очень поможет.

> Данных за день 100 гигабайт.

Именно 100 гигабайт данных в день? Тогда эти данные должны складываться в БД на выделенном сервере, а проблем с индексацией в современных БД нет.

Или таки 100 гигабайт логов в день? Серьезно? Нет, правда? 100 гигабайт логов в день? Интересно, на каких дисках и какой файловой системе лежит ваш /var/... Но тем не менее:

1. Логи можно разбить по разным файлам (см. пример – разделение /var/log/messages и /var/log/secure). Разным программам (или facility) назначаются разные файлы, получаем даже лучше чем с индексами – логи текстовые и без геморроя.

2. Конечно, изобретать свой формат БД – это круто. Но большинство современных сислог-демонов умеют складывать свои логи в базу. Настоящую базу данных, а не сделанную дятлом на коленке, пусть даже очень трудолюбивым дятлом.

3. Греп работает с логами на скорости файловой системы. И хитрый формат логов сделает их считывание только медленнее.

4. А кроме того, когда по логам нужно собрать какую-нибудь хитрую статистику (обычное дело логов httpd и squid-а), то собрать ее с помощью perl-а (а лучше awk – он быстрее) на порядок удобнее и быстрее, чем пайпить вывод systemd-шных утилит, однако.

5. И это еще без всяких плюшек, вроде logrotate-а со сжатием старых логов, отправкой копии лога на выделенный сервер для IDS-а и т.д.

Итого, по всем пунктам, классические текстовые логи удобнее, фичастее, быстрее, надежнее. Так что там с плюсами?

680 КБ

Думаю, что на каждой системе будет разный размер, но порядок примерно такой.

Логично. И это находится где-то в районе верхней границы разумного. Такие объемы и удалять практически нет смысла.

Это за двое суток. Точнее за сутки. Если ещё точнее, то за пару часов. Виновников я нашёл.

Это как раз хорошо, что лог набился, потому что интересно, как соотносится объем сислога и журнала на одних и тех же данных.

rsyslog же запущен? Значит в /messages должны быть примерно теже данные, что и в журнале.

Было бы идеально обнулить весь /var/log, затем перезагрузиться и накопить хотя бы пару сотен мегов логов.

И посмотреть du -sh /var/log и /var/log/journal.

И еще через часик повторить замер, чтобы посмотрить инкремент размеров.

Этого нет. Возможно надо как-то настройки покрутить (какие?). Возможно пока ещё не реализовано.

Про настройки разговора не было. Был разговор про стандартную модель безопасности, основанную на правах доступах к конкретным файлам журнала. Каждый сервис, который стартует под своим пользователем, должен был получить свой файл журнала с владельцем - этим пользователем, как-то так.

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

На всяк пожарный, перевел пост Леннарта в список рассылки из данной новости.

http://bb.comp-house.ru/comp-house.repo/wiki/systemd-v38

Такие объемы и удалять практически нет смысла.

Удаление реализовано. Надо покрутить параметры в /etc/systemd. Поиграюсь с настройками, отпишусь поподробнее.

Было бы идеально обнулить весь /var/log, затем перезагрузиться и накопить хотя бы пару сотен мегов логов.
И посмотреть du -sh /var/log и /var/log/journal.

Поиграюсь вечером, хотя не обещаю, что именно сегодня. Одна беда у меня, бинарь приходится смотреть через либастрал, поскольку программа просмотра логов собралась как-то криво, либо я что-то делаю не то. Хотя сильно это не напрягает. Кое-какой текст там всё-таки проскакивает.

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

Я пока наблюдаю два файла: system.journal и user-${UID}.journal.

Подождём v39.

Одна беда у меня, бинарь приходится смотреть через либастрал, поскольку программа просмотра логов собралась как-то криво, либо я что-то делаю не то

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

А обещали по файлу на каждый сервис с нормальными именами типа ntpd.journal, system.journal etc.

Чиво-чиво??? Поттеринг же сказал, что везде у него будут 128-битные UUID, и каждый кто хочет пользовать его журнал, должен сегенрить себе UUID, а в бинологе везде и всюду будут лежать UUID.

Хотели бинарный лог? Жрите!!! :-)

Ох да - и еще даже сообщния об ошибках в поттеринговском идеале должны быть в UUID, и программы должны иметь UUID, типа такого:

UUID.df567890e3 == file not found
UUID.ca890346а4 == access denied
UUID.abcd6543ef8756 == named
UUID.438756abcde887 == httpd

и само сообещние соответственно будет выглядеть как
{ abcd6543ef8756,ca890346а4,/etc/resolv.conf }
{ ca890346а4,438756abcde887,/var/lock/subsys }

А те кто хочет ЭТО прочесть, должны использовать поттеринговскую мегаутилиту, которая восстановит по UUID-ам описание ошибки и имя приложния.

Что-то у меня усиленно логирует

Ох-хо-хо. А ведь мог бы сделать tail -f, и сразу бы всё увидел... :-)