LINUX.ORG.RU

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

 , , ,


0

2

Леннарт Поттеринг (Lennart Poettering) анонсировал новый экспериментальный релиз системного менеджера systemd v38, примечательный интеграцией наработок проекта Journal, в рамках которого развивается подсистема, призванная заменить собой службу syslog и другие сопутствующие сервисы журналирования событий. Подробный обзор особенностей Journal и отличий от syslog можно прочитать в первом анонсе проекта.

Сообщается, что работа над Journal уже близка к завершению, остаётся нереализованными лишь несколько значительных функций и недостаточно проработана документация. Наиболее заметно наличие Journal при выполнении для сервисов команды 'systemctl status', которая теперь выдаёт в том числе и последние сообщения лога для указанного сервиса. Для совместимости с классическим syslog в systemd интегрирована специальная прослойка, которая использует сокет /run/systemd/journal/syslog для приема сообщений, включая перенаправление сообщений из /dev/log.

Данные сохраняются в /var/log/journal, если такая директория создана, в противном случае лог сохраняется в /run/log/journal. Для просмотра журнала следует использовать утилиту systemd-journalctl, которая по умолчанию генерирует вывод, полностью аналогичный формату /var/log/messages. Используя опции "-o verbose", "-o short-monotonic" или "-o json" можно менять детализацию и формат вывода. Для эмуляции поведения «tail -f» предусмотрена опция "-f".

>>> Подробности

Ответ на: комментарий от imul

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

ну хоть что-то. Я подумал, что там вообще один файл.

AVL2 ★★★★★
()
Ответ на: комментарий от no-dashi

Лол. Логгер без возможности прочитать логи — это прекрасно.

geekless ★★
()
Ответ на: комментарий от no-dashi

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

неправда ваша.

AVL2 ★★★★★
()
Ответ на: комментарий от no-dashi

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

прочесть в сыром виде труднее, а разобрать и визуализировать проще.

Мега-утилита напишет тебе не «file not found», а «фаил не найден».

AVL2 ★★★★★
()
Ответ на: комментарий от AVL2

Т.е. чтобы этой херней нормально смотреть логи, придётся еще и запускать её через env LANG=C каждый раз? Спасибо, не нужно.

geekless ★★
()
Ответ на: комментарий от AVL2

неправда ваша.

https://docs.google.com/document/pub?id=1MqQpm-ey8yVDPY8QVL155pvivay3Ut09dKxe...

Смотри в конце документа. И вот еще цитата из одного из перевода (не моего!) который тут раньше обсуждался:

С целью сделать записи узнаваемыми для клиентских утилит, записи журнала могут опционально нести 128bit иденитификатор в MESSAGE_ID=, установленый службой генерации сообщений. Этот ID должен быть случайно сгенерирован разработчиком во время разработки. К примеру, один ID для “Пользователь вошел в систему” и другой для “Пользователь вышел”. Все записи для этих событий будут обязаны нести 128bit ID что сделает их простыми для распознавания, и автоматически индексированными по этому полю. Это хорошая идея, использовать идентификаторы, совместимые с RFC4122 UUID тип 4, тем не менее это требование не является таким уж обязательным. Данное условие указано с целью обеспечить совместимость с другими системами журналирования, которые используют UUID-ы для идентификации типов сообщений, таких как логи прошивок UEFI. Если посмотреть на эти глобальные 128bit ID коды ошибок, то можно заметить, что в силу их случайности, не требуется центрального стандартизирующего органа, который присваивает цифровые ID конкретным типам сообщений. Присваивание идентификатора сообщения в целом необязательно, и мы ожидаем, что только малая часть журнала будет нести их, например, только те из них, которые необходимо распознавать из пользовательского окружения. Если разработчику нужен новый 128bit ID для присваивания новому типу сообщений, который он вводит, то все, что ему надо, это выполнить “cat /proc/sys/kernel/random/uuid” который вернет новый UUID при каждом вызове. 128bit ID также могут быть использованы для реализации локализованных сообщений пользовательских интерфейсов, которые смотрят в каталог сообщений на нужном языке и представляют пользователю переведеное сообщение в всем интерфейсе программы.

Де-факто, возможность писать сообщения без UUID сделана только для совместимости с syslog (которую Поттеринг начнет целенаправлено ломать после набора «критической массы» дистрибутивов с systemd-v38-and-newer).

no-dashi ★★★★★
()
Ответ на: комментарий от Pakostnik

Откуда дровишки - машину времени брал напрокат?

myhand
()
Ответ на: комментарий от anonymous

успевает писать, а вот искать в этом беспределе часто не очень быстро и не очень точно.

OxiD ★★★★
()
Ответ на: комментарий от geekless

Т.е. чтобы этой херней нормально смотреть логи, придётся еще и запускать её через env LANG=C каждый раз? Спасибо, не нужно.

а программы ты как запускаешь, когда хочешь увидеть английский (или не английский, но все равно недефолтный) интерфейс?

AVL2 ★★★★★
()
Ответ на: комментарий от no-dashi

С целью сделать записи узнаваемыми для клиентских утилит, записи журнала могут опционально нести 128bit иденитификатор в MESSAGE_ID=,

Мы говорили об именах файлов, а не об опциональном параметре к записи в журнале.

Де-факто, возможность писать сообщения без UUID сделана только для совместимости с syslog (которую Поттеринг начнет целенаправлено ломать после набора «критической массы» дистрибутивов с systemd-v38-and-newer).

это больше эмоции. UUID по сути своей опционален. Объяснить его обязательность можно будет только ориентацией автора...

AVL2 ★★★★★
()
Ответ на: комментарий от no-dashi

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

Собственно я так и поступил. Текст кое-какой проскакивает. По нему хотя бы источник проблем получилось определить.
Вообще это не радует. Рандомная ююйдность идентификаторов на мой взгляд вообще спорное «достоинство».
Надеюсь это хозяйство не скоро попадёт в мейнстрим. Сыстемдэ пилилось примерно год до терпимого состояния. А здесь вообще пока кино и немцы. А дома мне старому всё-равно. У меня в этом разделе джента именно для блад-тестов и поставлена.

imul ★★★★★
()
Ответ на: комментарий от imul

PS: я тут что, единственный пре-альфа-тестер? Хоть кто-нибудь, составьте компанию, а то писать гневные очевидные постинги о том как надо правильно я и сам умею. :D

imul ★★★★★
()
Ответ на: комментарий от imul

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

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

AVL2 ★★★★★
()
Ответ на: комментарий от AVL2

А я подумываю о том, чтобы к rsyslog прикрутить Input module, который будет из systemd'шного сокета таскать события :-)

no-dashi ★★★★★
()
Ответ на: комментарий от segfault

Я так скажу. Там где, к примеру, мне нужно, что бы _действительно_ грузилось/работало быстро, кастомный инитскрипт и замену udev/mdev я калякаю сам. В остальных случаях как то абсолютно похрен, сколько оно там грузится. Минуту, две, может 5, если рейд-контроллер тормозной

vasily_pupkin ★★★★★
()
Ответ на: комментарий от Reset

У тебя или плохая карма, или плохое железо, или ты лукавишь

vasily_pupkin ★★★★★
()
Ответ на: комментарий от Reset

Да. В венде просто зависает все набуй. Вместе с эксплорером, музлом, офесом в диалоге открытия итд итп. Но это конечно же не 12309

vasily_pupkin ★★★★★
()
Ответ на: комментарий от AVL2

Тогда возможно до ума за полгода и доведут для широкого бета-тестирования. Посмотрим.

imul ★★★★★
()
Ответ на: комментарий от Reset

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

vasily_pupkin ★★★★★
()
Ответ на: комментарий от CYB3R

Подскажите дистры, принципиально не одобряющие поделки Поттеринга.
Кроме гетны/арча, конечно.
Кроме арча

у меня для тебя грустные новости

stevejobs ★★★★☆
()
Ответ на: комментарий от vasily_pupkin

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

Я ж тут уже говорил (кажись, модераторы выпилили), что речь не о сервере, а о десктопе, долгая загрузка которого все-таки огорчает.

segfault ★★★★★
()
Ответ на: комментарий от vasily_pupkin

Есть хибернейт.

...и 16 гигов ОЗУ, которые а) нужно где-то разместить, б) поднимаются с диска намного дольше загрузки системы.

segfault ★★★★★
()
Ответ на: комментарий от segfault

У меня одного файерфокса 4 окна, которые автоматически по тегам никак не раскидать... Скринов тоже пяток с 5-10 табами в каждом...

Binary ★★★★★
()
Ответ на: комментарий от Binary

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

segfault ★★★★★
()
Ответ на: комментарий от Binary

У меня одного файерфокса 4 окна, которые автоматически по тегам никак не раскидать

фуррипроблемы.

Скринов тоже пяток с 5-10 табами в каждом...

ssh сессия при гибернации отвалится же, один хрен.

anon8
()
Ответ на: комментарий от segfault

Не, я просто раскидываю по окнам релевантно задаче и ничего не напрягает.

Binary ★★★★★
()
Ответ на: комментарий от anon8

фуррипроблемы

каково решение других браузеров?

ssh сессия при гибернации отвалится же, один хрен.

так локально же всё. хотя на работе я тупо никогда не отключаю комп :)

Binary ★★★★★
()
Ответ на: комментарий от Binary

каково решение других браузеров?

Opera просто сохраняет сессию, со всеми окнами и вкладками.

так локально же всё.

а зачем тогда screen?

anon8
()
Ответ на: комментарий от anon8

Opera просто сохраняет сессию, со всеми окнами и вкладками.

FF тоже. только их же надо по тегам dwmовским распихать.

а зачем тогда screen?

вместо табов терминала + возможность в любое время детачить всю сессию через ssh.

Binary ★★★★★
()
Ответ на: комментарий от Binary

только их же надо по тегам dwmовским распихать.

Признаю, был не прав, не понял про тэги.

anon8
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.