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)

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

Блин, чувак, вали на винду. Всё равно же ты используешь для работы какую-то конкретную программу, а для комментов браузер, так какая разница?

На работе у меня и так венда.

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

Всем по^безразлично. Те, кому нужен линукс, выберут линукс.

Твоё мнение с полпроцента тоже по^... Ещё немного и линукс будет неудобней винды. И останется узкая ниша типа фрёвой - маленьким рутером работать на подсосе.

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

десктоп это уже ретроградство, все давно пересели на ноутбуки

Это совсем не так. Ноутбуки вымирают в пользу планшетов и смартфонов. А десктопы как были так и есть.

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

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

Оно и сейчас не тормозит.

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

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

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

Кстати, возможно, не сам RH, а Штеуд какой-нибудь спонсирует совместный проект по втыканию палок в колеса гуглу.

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

Да не читает он никакие логи! Неужели непонятно, что прыщавая школота, рефлекторно гавкающая при слове Поттеринг, в принципе к чтению не приучена? Какие, нах, логи - они даже пару абзацев из описания systemd прочитать второй год не могут!

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

Для унификации есть openlog/syslog. Маловероятно, что кто-то будет унифицировать дальше :D

fopen+fprintf+fclose есть везде, где есть стандартная библиотека C, причём платформоспецифичным будет разве что путь к файлу при его открытии. Хочешь сказать, что openlog/syslog обеспечивает бóльшую унификацию?

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

маленьким рутером работать на подсосе

Спасибо, именно такое мнение у меня и сложилось о невменяемых критиках Поттеринга, но врождённая интеллигентность не позволяла его озвучить.

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

Спасибо, именно такое мнение у меня и сложилось о невменяемых критиках Поттеринга, но врождённая интеллигентность не позволяла его озвучить.

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

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

Вопрос с подвохом. Зачем ты парсишь логи при загрузке?

LOL, что?

Ты вообще в курсе что такое Systemd?

При загрузке читаются конфигурационные файлы, Systemd и был разработан именно для ускорения загрузки системы.

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

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

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

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

LOL, что?

Лолто - вот с этого все началось:

Почитал комментарии и заметил что часто встречается критика того что логи ведутся в бинарном виде.

А теперь, второй вопрос!

При загрузке читаются конфигурационные файлы, Systemd и был разработан именно для ускорения загрузки системы.

Где в systemd бинарные конфигурационные файлы?

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

Скорость загрузки системы может быть немного быстрее если заменить обработку текстовых файлов на обработку бинарных файлов.
При загрузке читаются конфигурационные файлы, Systemd и был разработан именно для ускорения загрузки системы.

LOLWUT? У systemd ещё и конфиги бинарные [будут]???

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

Они вообще всякую гадость используют в последнее время без санитарной экспертизы

Это в смысле тебя забыли спросить? Не задумывался, почему именно разработчики udev, к примеру, делают так, как им удобнее, не спрашивая тебя? Может быть потому, что у тебя кроме баттхёрта ничего за душой нет, а?

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

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

Это в смысле тебя забыли спросить?

Это в смысле - «как влетело, так и вылетит» при появлении более вменяемой альтернативы.

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

Зачем ты парсишь логи при загрузке?

При загрузке читаются конфигурационные файлы

Мсье видит разницу между конфигами и логами? Присоединяюсь к вопросу: зачем при загрузке парсить логи?

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

Почему ты считатешь это решение нормальным в ситуации с десктопом?

Какая разница? За логами десктопа нужно следить также, как логами сервера. Десктопы троянят, как и сервера, на них могут после обновления слететь какие-то сервисы, и логи на них нужны для той же цели. Journald — это как каменный век, когда деревья сервера были большими, логи маленькими, и админ мог читать все логи подряд. А сейчас нормальный админ не будет заниматься мазохизмом, итак работы хватает.

Хоть на десктопе, хоть на сервере, один раз настроить и больше не морочить себе голову удобнее, чем раз в несколько месяцев (умножить на число машин), когда надо смотреть логи, запускать journalctl, видеть кучу спама, перезапускать его с фильтром, видеть чуть меньше спама, перезапускать его с новым фильтром и т.д. Это — пустая трата времени/денег.

Компьютеры придумали чтобы экономить время, а не отнимать его. Я не хочу тратить свое время впустую, я хочу видеть в уведомлениях logwatch-а только важные для меня сообщения. Я не хочу тратить место впустую, а хочу, чтобы важные для меня логи logrotate хранил дольше, а неважные удалял чаще. Хочу, чтобы работающий от отдельного юзера скрипт имел доступ к логам собственного демона. Только ой... в journald это невозможно, и аналогов logwatch и logrotate для systemd/journald нет... А передача логов по HTTP-запросам — это вообще писец безопасности.

в ситуации с десктопом?

Если «десктопом» считать машину, на которой логи никто не читает, то там ни syslog ни journald не нужен. Но причем тут десктоп? Думаешь, systemd/journald не будет в RHEL7?

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

им кто-то мешает унифицироваться?

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

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

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

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

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

За счёт чего ускоряет? И в каком месте? Мне стало интересно, правда.

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

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

Ни разу не верно!

Добавить в лог - дописать последовательность байт после SEEK_END.

В бинарном формате можно не конвертировать дату/время/pid и сэкономить на этом. Но придется перестраивать индекс (а журнал у Лени индексированный!), на чем потеряется ПРОРВА времени.

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

Перестраивать индекс не придется. Записи не удаляются и не модифицируются. То есть получаем специализированную NoSQL базу.

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

Ни разу не верно!
Добавить в лог - дописать последовательность байт после SEEK_END.

Так запись байт в файл быстрее чем обработка и изменение текстовых строк в файле.

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

Хоть на десктопе, хоть на сервере, один раз настроить и больше не морочить себе голову удобнее, чем раз в несколько месяцев (умножить на число машин), когда надо смотреть логи, запускать journalctl, видеть кучу спама, перезапускать его с фильтром, видеть чуть меньше спама, перезапускать его с новым фильтром и т.д. Это — пустая трата времени/денег.

И в чем проблема? Кто тебе не дает использовать logwatch, если тебя это устраивает?

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

Десктопы будут нужны всегда

нет, они уже сейчас не нужны

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

Так запись байт в файл быстрее чем обработка и изменение текстовых строк в файле.

Посмотри уже исходник fputs. И никакого «изменения» в случае журнала тупо нет.

sergv
()

HTTP? HTTP устарел и надо было обеспечить поддержку websocket'ов. Ну и конечно же надо все это под ssl засунуть. А если ssl то надо инфраструктура PKI втягивать. Да, втягивать это надо именно в journald так как нельзя же было настроить это syslog+nginx/httpd+openssl.

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

А этим пользоваться действительно удобно, если не брать во внимание специальные случаи

Ты это серьёзно? Удобно пользоваться? Давай ты с его помощью последишь месяц за ВСЕМИ логами хотя бы одной машины, а потом расскажешь? Простой десктопной машины, на которой, например, из сетевых демонов только ssh и samba/ftp. Для syslog+logwatch это легко. Справишься с такой задачей для journald?

С journald ненужное стало удобным, а нужное нереальным. Он делает лог бесполезным. Читать его теперь никто не будет — вручную это делать слишком тяжело, а управлять логом автоматически невозможно.

Если это действительно нужно, то есть форвард в средства генерирующие формат для кофеварок. Если нет, см. п. 1

А если всё равно экспортировать всё в сислог и работать только с сислогом, то зачем козе баян?

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

А если поставить ssd, то пох что там systemd, sysvinit, openrc, upstart или венда. грузится с нуля будет быстрее пули, а уже про hibernate вообще молчу

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

Перестраивать индекс не придется. Записи не удаляются и не модифицируются. То есть получаем специализированную NoSQL базу.

Индекс в памяти? Для хотя-бы парочки сот тысяч записей в день?

Круто, ага!

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

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

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

Видимо те кто критикуют за бинарный формат данных не программисты вовсе

Видимо те, кто агитируют за бинарный формат, понятия не имеют о чем они говорят.

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

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

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

Так запись байт в файл быстрее чем обработка и изменение текстовых строк в файле.

И в каком же месте происходит изменение «текстовых строк в файле»? Хорошо бы посмотреть на место в исходниках rsyslog, где происходит сие непотребство.

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

Посмотри уже исходник fputs. И никакого «изменения» в случае журнала тупо нет.

Запись/чтение текста в виде последовательности символов в файл медленнее чем запись/чтение байт в файл.

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

Ты это серьёзно? Удобно пользоваться? Давай ты с его помощью последишь месяц за ВСЕМИ логами хотя бы одной машины, а потом расскажешь? Простой десктопной машины, на которой, например, из сетевых демонов только ssh и samba/ftp. Для syslog+logwatch это легко. Справишься с такой задачей для journald?

Что бы обоснованно троллить Поцтеринголюбителей, я поставил все эти поделия на одну из своих тачек, и с весны этим всем ежедневно пользуюсь. Правда мой юзкейс использования логов несколько отличается от «следить за ВСЕМИ логами», в сторону - смотреть в логи если что то поломалось.

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

управлять логом автоматически невозможно

Невозможно, если очень этого не хотеть

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

Запись/чтение текста в виде последовательности символов в файл медленнее чем запись/чтение байт в файл.

Чем байт с кодом символа отличается от байта поттерлога?

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

не трогаешь + не включаешь + не пользуешься == удобно.

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

При чем тут память? Индексы можно писать в тот же файл (что и происходит), но это не обязательно должно быть B-tree.

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

Индексы можно писать в тот же файл (что и происходит), но это не обязательно должно быть B-tree.

А что в поттерлоге конкретно? Я, честно, не вкурсе совсем.

Да. И времени даже на создание нового индекса хоть в виде ссылок один фиг потратить придется. Плюс дисковый ввод/вывод на поиск.

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

Почему по твоему тестовые файлы с данными весят больше чем бинарные файлы с теми же самыми данными.

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

Индекс в памяти? Для хотя-бы парочки сот тысяч записей в день?

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

А если моя догадка верна, то есть два варианта:
1. Journald хранит все индексы в памяти, периодически сбрасывая их на диск
2. Либо никаких индексов нет, это миф, а внутри там полный пробег по логу с самописным аналогом грепа

Я склоняюсь к п.2

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

Почему по твоему тестовые файлы с данными весят больше чем бинарные файлы с теми же самыми данными.

ORLY? Примеры, надеюсь, будут. А тут у меня sql в качестве контрпримера вырисовывается.

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

Запись/чтение текста в виде последовательности символов в файл медленнее чем запись/чтение байт в файл.

Ойли?

С исходниками glibc напряг - сходу не нагуглились. Возьмем, как пример, из FreeBSD

http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/stdio/fwrite.c?rev=1.14

http://www.freebsd.org/cgi/cvsweb.cgi/src/lib/libc/stdio/fputs.c?rev=1.12

Ага, блин. На целый strlen дольше ;-)))

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

А что в поттерлоге конкретно?

Не в курсе. Видел, что формат журнала еще не стабилизировался, нормальной документации нет. Т.е. пока с ним разбираться рано.

И времени даже на создание нового индекса хоть в виде ссылок один фиг потратить придется.

Насколько я понял, все индексы создаются заранее. Для логов сразу понятно, что надо индексировать, это не база общего назначения.

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

Насколько я понял, все индексы создаются заранее. Для логов сразу понятно, что надо индексировать, это не база общего назначения.

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

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

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

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

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

Во-во. А то «индексы, бинарный поиск, ускорение»...

Однако, хэш посчитать - тоже CPU надо. Да и «хранить немного хэшей» - память надо.

Ну и где выигрыш в скорости?

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

Что бы обоснованно троллить Поцтеринголюбителей, я поставил все эти поделия на одну из своих тачек, и с весны этим всем ежедневно пользуюсь. Правда мой юзкейс использования логов несколько отличается от «следить за ВСЕМИ логами», в сторону - смотреть в логи если что то поломалось.

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

Невозможно, если очень этого не хотеть

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

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