LINUX.ORG.RU

Systemd 194, теперь с HTTP-сервером и генератором QR-кодов

 


3

3

Выход очередной версии init-демона systemd продолжает радовать пользователей новыми встроенными функциями.

В частности:

  • опция HandleSleepKey в logind.conf была разбита на HandleSuspendKey и HandleHibernateKey, старая опция более не доступна;
  • почти полностью удалена утилита multi-seat-x, минимальная обертка оставлена до тех пор, пока DM не начнут поддерживать новую логику перечисления графических устройств Xorg;
  • nspawn теперь создает символическую ссылку /etc/localtime в окружении контейнера;
  • исправлено поведение при отсутствии /etc/vconsole.conf, теперь в этом случае не будет загружаться никакой шрифт;
  • journald теперь пишет в лог максимальный размер, который файлы журнала могут занимать на диске;
  • опция параметра journalctl -n теперь необязательна и по умолчанию равна 10;
  • journalctl -f теперь реагирует на изменение размеров терминала и разбивает строки соответственно;
  • новая опция --cursor в journalctl позволяет выводить записи начиная с определенного места журнала;
  • добавлена поддержка journalctl для bash-completion.

Но две функции привлекли особое внимание. Их заметили пользователи федоры, которые при обновлении обнаружили, что systemd теперь зависит от libmicrohttpd и qrencode. Это стало причиной активно продолжающегося обсуждения в рассылке.

Оказалось, что обе функции связаны с journald — собственной заменой syslog-демона, как известно, входящей в состав systemd. Среди прочего, он отличается тем, что ведет логи в бинарном виде вместо текстового.

Зависимость от qrencode объясняется реализацией функции Forward Secure Sealing, journalctl из состава systemd использует qrencode для вывода QR-кодов в текстовой консоли.

А поскольку логи хранятся бинарно, для работы с ними нужны дополнительные программы. Зависимость от libmicrohttpd вызвана тем, что в состав systemd теперь входит встроенный http-сервер journald-gateway, умеющий отдавать логи в текстовом и json-формате. Его основное предназначение автор видит в синхронизации журнала по сети.

Так выглядит http-сервер journald-gateway в действии

>>> Леннарт про FSS и QR-код

anonymous

Проверено: JB ()
Последнее исправление: Silent (всего исправлений: 3)
Ответ на: комментарий от vasily_pupkin

Гипотетически выигрыш должен быть на чтении, т.е. на грепе, а не на записи

Т.е. Леннарт изначально всё рассчитывает на такую стабильность/надёжность, при которой читать логи придётся чаще/больше, чем писáть? Молодец, чо. :)

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

Любопытно, а как ты узнаёшь, что что-то поломалось, не читая логи? Приведи какой-нибудь пример недавнего случая?

Ну например у меня при логауте не отмонтировался шифрованный раздел.

Позырил journalctl _COMM=lightdm, и все дела. Или VPN не коннектится. Поставил journalctl _SYSTEMD_UNIT=NetworkManager.service -f и зырю. Итп.

С journald невозможно. Можно делать экспорт в сислог и работать с сислогом, но зачем тогда нужен journald?

Посмотри как работает logwatch

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

....то причина поломки системы — в том что — У ВАС ИСПОРТИЛИСЬ ДИСКИ!

нет, придурок, это следствие.

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

Пока вижу, что используется таблица с хэшами.

Странно... По хеш-таблице нельзя делать поиск диапазонов. Значит как минимум поиск по диапазону дат там работать не может.

А таблица хранится целиком в памяти или подгружается с диска? В смысле, он её строит на лету в памяти по ходу лога, или хранит и обновляет на диске?

Кстати, может это вообще не для поиска хеши, а его проверка целостности, для которой сабжевые QR-коды выводятся?

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

Чего-то я не понял. Это как - заранее создать индекс для еще несуществующих записей???

Имел ввиду, что индекс создается для таблицы. Т.е. таблицу с данными не надо заново индексировать.

Даже если мы только добавляем, то надо для каждой новой записи давать ссылки на записи типа больше/меньше/равно.

Для некоторых полей поведение известно заранее. Т.е. время всегда будет больше предыдущего, хостнейм известен, установленные/запускаемые демоны тоже (это все таки система инициализации ;) ) и т.д. Т.е. возможна некоторая оптимизация.

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

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

Да ну?! Что вы говорите, прямо без всяких, да? Даже без cat? Это интересно весьма, жгите дальше. Бинарные логи - это не единственный способ систематизировать их содержимое, но уж всяко этот способ лучше логов в XML.

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

Да, матчи в journalctl это полный провал. Нужно больше багрепортов :D

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

Да ну?! Что вы говорите, прямо без всяких, да? Даже без cat?

Тебе явно же сказали «дополнительных». Четыре звезды натроллил, а читать так и не научился. И это прискорбно.

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

шелл-то у тебя точно есть, без него journalctl не запустить

Внимательно читаем тему, с которой весь сыр бор.

в состав systemd теперь входит встроенный http-сервер journald-gateway, умеющий отдавать логи в текстовом и json-формате

PROFIT! :D

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

Я не разбирался детально с кодом (ИМХО это делать пока рано).

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

При повреждении он мне пару раз создал новый файл лога, но не всегда. Зависимости не нашел.

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

Имел ввиду, что индекс создается для таблицы. Т.е. таблицу с данными не надо заново индексировать.

Мы-ж к ней добавляем постоянно! Как это - не надо?

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

Бинарный лог можно прочитать только одной конкретной тулзой, в отличие от.

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

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

Хотел сказать, что в данном случае некоторая оптимизация возможна.

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

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

Ой как ты не прав

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

Ну как бы логи наверное нужны что бы их читать/смотреть итп, а не хранить для красоты?

Ну как бы логи читают/смотрят, когда что-то не работает или работает неправильно, разве нет? И если софт не похож на федору регулярно глючащее творение Поттеринга говнокодера, то запись в лог будет происходить [значительно] чаще, чем чтение и анализ. И накой чёрт тогда всё усложнять, превращая логгер в СУБД?

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

Ну например у меня при логауте не отмонтировался шифрованный раздел. Позырил journalctl _COMM=lightdm, и все дела.

Шифрованный раздел должен был отмонтировать lightdm?

Или VPN не коннектится. Поставил journalctl _SYSTEMD_UNIT=NetworkManager.service -f и зырю.

Ок, понятно, спасибо.

Могу сказать что лично для меня неудобное стало удобным.

А почему `journalctl ...` это удобно, а какой-нибудь `grep pptp` или `grep lightdm` неудобно? По-моему, никакой разницы.

Посмотри как работает logwatch

Работает с отдельными файлами сислога, я указываю с какими. Могу выбрать, какие файлы игнорировать, какие сервисы мне не нужны и т.д. С journal-ом не работают. А что?

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

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

Они есть? Нет. Спеки есть? Нет. Гарантия стабильности формата есть? Нет. Как видишь, нет ни одной причины, чтобы они появились.

Во-вторых, не вижу никакой трагедии в том, что нужна тулза.

Напротив, это комедия

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

А не надо на губах играть потому-что. Вечно вендузятники всё в рот тянут.

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

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

Еще тем, кто предпочитает нормальные мониторы, клавиатуры и мыши.

dm1024 ★★★
()

Улыбаюсь во все зубы. Развалит потя красношапку... ой развалит.

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

Основная причина запила бинарного формата - желание запихать в лог побольше информации, причем черт знает какой. Причем с нестабльным на первых порах количеством полей итд. Причем с API для чтения. Проще всего это было запилить с бинарным форматом. Потом туда нахренячили всякой муры типа индексов итп, но это вторично. Текущему решению до СУБД как до китая раком.

Я плюс такой системы вижу в упрощении систем автоматизированной обработки. Как там будет по факту - увидим через некоторое время

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

Они есть? Нет. Спеки есть? Нет. Гарантия стабильности формата есть? Нет. Как видишь, нет ни одной причины, чтобы они появились.

Вообще-то есть документированный API и промис что его не поломают

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

То что стоит предложить ты и сам знаешь. Зачем спрашиваешь?

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

Вообще-то есть документированный API и промис что его не поломают

К мною перечисленному это не относится и переносимость не гарантирует.

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

...и промис что его не поломают

Ага. А еще они там с Сиверсом про сборку udev что-то обещали-обещали. Невнятно так обещали. Сейчас вон отмазы строят.

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

Шифрованный раздел должен был отмонтировать lightdm?

Шифрованный раздел отмонтируется pam_mount в конце сессии. Конец сессии - конец логин менеджера. Логин менеджер у меня lightdm.

А почему `journalctl ...` это удобно, а какой-нибудь `grep pptp` или `grep lightdm` неудобно? По-моему, никакой разницы.

Тут есть пара важных моментов. Во-первых есть разница между просто грепом и грепом по метаинформации. Заключается она в следующем. Я привел пример с NM. NM при работе стартует кучу других программ, они называются по разному и имеют в логах разное поле COMM,pid. Тем не менее, systemd их метит как пренадлежащие одному сервису. Таким образом я могу смотреть все то, что касается конкретно взятого сервиса вне зависимости от программ. Во-вторых просто греп по строке дает ложные срабатывания при появлении куска по которому мы грепаем.

Второй момент, который я уже упоминал - все логи в одном месте. В т.ч. и выхлопы stdout/stderr (впрочем там есть некоторые ограничения). В чем удобство - не надо грепать все подряд.

Скорость - не знаю. Субъективно кажется, что journal MATCH -nX быстрее чем grep /var/log/something | tail -nX. Замеров не делал.

Работает с отдельными файлами сислога, я указываю с какими. Могу выбрать, какие файлы игнорировать, какие сервисы мне не нужны и т.д. С journal-ом не работают. А что?

Этот набор костылей работает с |, так что вместо cat /var/log/some-shit можно юзать journalctl MATCH, например. Остальное останется прежним. Т.е. количество допила мало, просто пока никто не запилил.

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

Поживем увидим. Пока патч в генте обеспечивающий это достаточно мал

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

Во-первых таких тулз может быть сколько угодно

К мною перечисленному это не относится и переносимость не гарантирует.

А я считаю что относится. Нет причин городить еще-один-парсер-XML^W^H когда есть либа, которая это реализует, и есть API.

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

Вообще-то да. Попробуй напиши и посмотри сколько у тебя это займет времени. Потом запости сюда, и я скорее всего найду ошибку.

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

Видимо ты никогда не видел продакта, когда нужно (1) - аудит, (2) постоянный поток жалоб от клиентов, и нужно по логам разбирать где ошибка - в кривых руках юзера или это баг в системе.

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

В этом случае систему лучше перегрузить. Помимо инита многие процессы могут вести себя неадекватно.

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

А я считаю что относится. Нет причин городить еще-один-парсер-XML^W^H когда есть либа, которая это реализует, и есть API.

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

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

Видимо ты никогда не видел продакта, когда нужно (1) - аудит, (2) постоянный поток жалоб от клиентов, и нужно по логам разбирать где ошибка - в кривых руках юзера или это баг в системе.

Видимо ты тоже его не видел.

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

К C биндинги пиляться под что угодно. C ОС похуже - там во всю используется mmap, так что как минимум из коробки какой нибудь MSVS это не соберешь

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

нужно по логам разбирать где ошибка - в кривых руках юзера или это баг в системе

Чем это отличается от приведённого мной примера с «работает неправильно»?

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

Особенно удобно было перезагружать продакт серваки, которые стояли по 2 года аптайма, и никто не знает загрузятся ли они обратно или нет.

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

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

Просто была догадка, что это не индексы вовсе. Точнее, это не индекс для поиска, а в лучшем случае цепочка хешсумм для контроля целостности лога (чтобы убедиться, что лог не меняли), ну, то о чем в сабже про QR-коды написано.

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

...

А вообще смотрю я journalctl.c и вижу там только HASHMAP_FOREACH по файлам. Похоже, индексы — миф, и внутри там просто урезанный греп.

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

С каких это пор разработчики OpenSUSE, Mageia работают в RedHat?!

С каких пор у разработчиков зюзикса и мандрейка есть свое мнение? Их судьба - мечтать о том, как они догонят Редхат.

Arch

Бугага.

Чем больше ты

Твое мнение очень важно для меня.

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

Да ну?! Что вы говорите, прямо без всяких, да? Даже без cat?

Даа, существует 1001 способ чтения текстового файла без cat, представьте себе.

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

А что делать? Сталкивался с такой ситуацией. Гарантировать, что все сервисы продолжают нормально работать после отката времени, ИМХО, невозможно.

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

Потому что это нормальная работа системы чуть сложнее твоего локалхоста.

Ну, если «постоянный поток жалоб от клиентов» — это нормально, тогда ладно.

anonymous
()

черт, рхел 7 еще даже до беты не дошел, а уже такое бурление говн :D у вин серверов может появиться неплохой шанс оторвать жирный кусок продакшн установок

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

А вообще смотрю я journalctl.c и вижу там только HASHMAP_FOREACH по файлам. Похоже, индексы — миф, и внутри там просто урезанный греп.

ldd /bin/systemd-journalctl | grep systemd
        libsystemd-journal.so.0 => /lib/i386-linux-gnu/libsystemd-journal.so.0 (0xb76ce000)
        libsystemd-id128.so.0 => /lib/i386-linux-gnu/libsystemd-id128.so.0 (0xb76c6000)

Это дебиан, т.е. не последняя версия система В исходниках

#include <systemd/sd-journal.h>

Т.е. он пользуется их api

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

Да ну?! Что вы говорите, прямо без всяких, да? Даже без cat?

Чему только в институтах учат?.. Ключевое слово «дополнительных». А cat - программа общего назначения. Разницу дальше объяснять?

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