LINUX.ORG.RU

Новый релиз systemd 195

 


0

1

Lennart Poettering продолжает развивать свое творение, внося в него новые возможности. В свежевыпущенный релиз внесены следующие изменения:

  • journalctl получил новые параметры --since= и --until= для фильтрации по времени. Также теперь поддерживается фильтрация по юнитам через --unit=/-u.
  • journald теперь поддерживает ротацию и очистку журнала по времени в дополнение к уже имевшейся ротации по занимаемому месту.
  • journal теперь индексирует имеющиеся значения полей для каждого поля. Это позволяет клиенту просмотреть имеющиеся значения при фильтрации. В соответствии с этим обновлены bash completion. journalctl получил новый параметр -F для просмотра имеющихся значений, которые принимает поле в базе журнала.
  • Большее количество сообщений сервисов теперь записываются в журнал как структурированные и распознаются по идентификатору.
  • Мини-сервисы timedated, localed, которые ранее предоставляли поддержку смены времени, локали и имени хоста только из графического окружения типа GNOME, теперь имеют и минималистичные (но весьма функциональные) консольные клиенты для управления. Возможно, теперь это самый приятный способ смены настроек из командной строки, в особенности потому, что в них присутствует полный список опций и они интегрированы с bash completion.
  • Новая утилита systemd-coredumpctl для получения списка и извлечения coredump-ов из журнала.
  • Теперь дистрибутив устанавливает README-файлы в /var/log/ и /etc/rc.d/init.d, которые поясняют, куда подевались журналы и скрипты инициализации. Автор надеется, что это поможет сориентироваться зашедшему в эти, теперь пустые, каталоги.
  • В gatewayd добавлено множество возможностей таких, как режим «follow» для режима немедленной синхронизации и фильтрации.
  • gatewayd/journalctl теперь поддерживают вывод типа HTML5/JSON Server-Sent-Events.
  • Логика режима совместимости с init-скриптами SysV теперь эвристически определяет поддержку скриптом ключевого слова «reload» и только при его наличии предоставляет возможность «systemctl reload».
  • Сервисы типа oneshot не могут использовать ExecReload=.
  • При запуске пользовательского сервиса (через systemd --user) переменная окружения $MANAGERPID устанавливается в PID systemd.
  • Посылка сигнала SIGRTMIN+24 пользовательскому экземпляру systemd приводит к его немедленной остановке.
  • В browse.html теперь доступны фильтрация и просмотр детальной информации для отдельных полей.
  • «systemctl status --follow» удалено, используйте «journal -u».
  • Опции journald.conf RuntimeMinSize=, PersistentMinSize= удалены как бесполезные при настройке.

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



Проверено: JB ()
Последнее исправление: Silent (всего исправлений: 6)

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

Надо же, до чего мараз^W техника дошла. А у меня он не падает (хотя он и говно и я, по возможности, его не запускаю, но когда запускаю, чото не падает, глюки есть другого рода). Такие дела.

Binary ★★★★★
()
Последнее исправление: Binary (всего исправлений: 1)
Ответ на: комментарий от vasily_pupkin

Ну это, в случае скайпа, как раз показывает всю костыльность подхода. При автоматическом перезапуске скайпа он: появится хрен знает на каком воркспейсе (если конечно его куда-то не прибить гвоздями), забудет все открытые ранее окна. Учитывая дефективность этого поделия, наверно, и ещё проблемы найдутся.

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

гм. надо меньше внимания уделять правке комментария.

зондеркоманду высылают, конечно же, к Столпам UnixWay чтобы под угрозой смерти они предали идеалы Unix-Way, KISS, DRY и прочих малорелевантных аббревиатур и пустили в свой дистрибутив systemd.

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

Ну это, в случае скайпа, как раз показывает всю костыльность подхода. При автоматическом перезапуске скайпа он: появится хрен знает на каком воркспейсе (если конечно его куда-то не прибить гвоздями), забудет все открытые ранее окна. Учитывая дефективность этого поделия, наверно, и ещё проблемы найдутся.

Ну почему же? Он появится там где надо. Я ж не системным истансом systemd его мониторю, а тем который в пользовательской сессии. Так что там все ок :]

И что самое главное - у меня теперь нет проблем рестартить это все как надо через ssh :D

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

так это ж для завершившихся, а не для неработающих, а для неработающих нужна магия, типа системы мониторинга, которая пинает вотчер (или инит) и говорит, что «ааа всё плохо».

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

зачем вы юродствуете?

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

Вот что вы посоветуете пользователям arch

В первую очередь я бы посоветовал потребовать деньги обратно. Что, не засылали денег? Хмм… тогда, наверное, следует сыграть на вложенном труде: «я, такой-то, заслал 20 патчей, поддерживаю 30 пакетов, в неделю трачу в вашем багтрекере 40 часов, крайне недоволен переездом на systemd и требую вернуть всё взад, а иначе я уйду». Что, не контрибутил? А что делал? Пользовался? И всё? И что же именно случится с дистром, когда ты перестанешь им пользоваться? Правильный ответ: «ничего». Поэтому ты бесполезен, а голос твой весит 0. Ешьте, что дают, или GTFO.

Ах да, ещё можно не апдейтиться. Ну и опять же форк, да.

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

Затратно, но реально

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

Не совсем понимаю как это должно работать, тем более некоторые идиотские сервисы любят делать for (....) close(fd).

для неадекватов, которые так делают есть wait.

Про супервизор я зря написал, да. openrc был приведен как пример системы со стейтом и с внешним хранением

не очень понял, мне показалось, что ты написал, openrc как пример супервизора, а я всего-лишь сказал, что он им не является, и не пытается и не будет пытаться. А максимум, что он предоставляет - команду status для проверки сервиса, но не более того.

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

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

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

для части сервисов никуда, часть можно под банальный супервижн повесить, плюс есть разница в том, что будет мониторинг писать в нужный сокет 'd', или шаманить через dbus. Про решения системд можете меня не спрашивать, в блоге поттеринга ответа нет, от василия ответы хоть и есть, но не на всё, а остальные апологеты системд сказать совсем ничего не могут/не хотят.

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

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

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

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

с другой стороны у меня есть сервер, на котором демонтулсы, там специфичные сервисы, для которых пкреподниматься через определенные интервалы времени это норма, но , знаете, мне проще поставить демонтулс, претензий к которому я так и не понял, потому что я знаю, что он делает конкретную вещь и не будет меня отвлекать не по делу (объяснять мне, что бинарные логи мне нужны кровь из носа, например)

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

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

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

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

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

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

2). возможность не иметь в системе дбас и прочие подсистемы, которые там не нужны.

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

4). возможность просто отдебажить, что происходит.

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

P.S. патч на поддержку cgroups_cpu уже есть, думаю к концу недели и на blkio и memory будет :)

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

кстати, ситуация с s/systemd/любой аналогичный сервис/ вполне возможна, хотя и убога by design.

да я уже думаю на eeepc так сделать для firefox, правда тут простого враппера хватит :)

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

правда тут простого враппера хватит

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

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

да я понимаю; в общем систем-д выставило интересный уровень презентации, какой может существовать комбайн (в особенности в UI), и теперь все дружно ждем, когда до этого уровня дотянутся и другие системы, но без того tradeoff, который вносит системд.

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

Смотрю вот в генте на эти сервис файлы (зачем мне их туда запихали?), документацию, понятно, читать лень, но как в systemd можно сконфигурировать, с какими ключами запускать сервис?

Что-то любопытство затянуло, качаю образ арча. Почему-то в голове крутится мысль: почему бы не сделать конвертор service-файлов в баш скрипты, чтобы можно было в полуавтоматическом режиме билдить арч без системд? В порядке бреда субботнего, арчем то и не пользовался ни разу.

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

Смотрю вот в генте на эти сервис файлы (зачем мне их туда запихали?), документацию, понятно, читать лень, но как в systemd можно сконфигурировать, с какими ключами запускать сервис?

системд-шные? было много ругани и в итоге решили, что включаются те сервисфайлы, которые есть у апстрима и да в общем-то и официально поддерживаемых систем, т.е. опенрц (ну и прочих инитсткриптов т.к. они совместимы) и системд. Существует способ их игнорировать.

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

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

пилится или даже уже есть, но множество функций системд выше, чем инитскриптов (за счёт под сервисов, которые считается, что существуют). А в целом про арч я не в курсе, в отличии от генты.

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

но множество функций системд выше, чем инитскриптов

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

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

Да не, спасибо, но мне лично оно не нужно, просто интересно было, жизнеспособна ли идея. Я уже посмотрел livecd арча, и интерес как-то пропал, тем более, что уже кто-то делает :)

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

что, действительно, все мейнтейнеры в арче за системд?

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

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

И я не стал. И не знай я про «Restart=» — тоже либо чинил бы, либо писал враппер-рестартер. Как я уже сказал, рестартилка — только приятная мелочь, не более. Всего лишь. Но даже она экономит время.

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

внезапно никто не запрещает завернуть сервис systemd ни в monit, ни в daemontools. Просто случится это в 90% несколько позже.

мне смысла системд не понять, хотя и много парился как-то с инит скриптами для той же джанги

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

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

1. недостаточно информации.

2. да, это фатальный недостаток. хотя вот лично мне типизированный IPC очень даже да.

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

4. сферические какие-то поломки у вас.

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

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

s6 например должен быть PID-1 - идеи?

4. сферические какие-то поломки у вас.

нет причин чтобы они перестали быть сферическими (ставить системд)

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

s6 например должен быть PID-1 - идеи?

я не понял, что вы написали.

нет причин…

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

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

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

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

До systemd этой проблемы не было, sshd привычно перезапускали по ssh даже не думая, что что-то поломается.

Че, правда?!

А я-то после пары залетов в этой ситуации, стал использовать service sshd reload. А оно вон че...

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

systemd это init + journal + система управления процессами и все это интегрированное решение, а не набор «сделай сам». Каждый компонент делает какое-то свое дело и весьма хорошо. Кстати сказки про монолит тоже не рассказывайте, это именно набор инструментов. Такой же как ваш sysvinit + набор костылей.

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

Debianовцы на полном серьезе такую хрень делают.

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

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

Венда головного мозга? Вон отсюда!

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

Каждый компонент делает какое-то свое дело и весьма хорошо.

Только почему-то /usr больше не монтируется отдельным разделом, а для того, чтобы посмотреть, что-же в загрузке пошло не так, надо перегружать систему в «дебаг-режиме». Весьма, да.

Кстати сказки про монолит тоже не рассказывайте, это именно набор инструментов.

Ну и воспользуйтесь, пожалуйста, этими инструментами по отдельности, продемонстрируйте нам правоту своих слов.

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

Давай, к примеру, посмотрим на initscripts от приведенных тобой iptables, httpd, sshd. Там, AFAIR(посмотреть сейчас негде, дома уже systemd) 90% копипейст, несмотря на то, что они «такие разные».

Давай посмотрим:

* sshd — кроме обычных запуска и остановки позволяет перечитать конфиг без перезапуска sshd (service sshd reload), на первом запуске автоматически генерирует ключи, если их нет. При переходе на systemd эти возможности были утрачены.

* httpd — кроме стандартных запуска/остановки, позволяет указать параметры для httpd в /etc/sysconfig/httpd, тоже позволяет перечитать конфиг без перезапуска, просто проверить конфиг (service httpd configtest), выполнить «вежливый» перезапуск (service httpd graceful) без обрыва текущих соединений, и еще несколько мелочей. Все эти возможности были утеряны при переходе на systemd.

* iptables — универсальный скрипт для iptables и ip6tables, который умеет кучу всего. Из /etc/sysconfig/iptables-config он берет список conntrack-модулей, которые нужно подгружать, и еще ряд настроек. Позволяет сохранить текущие правила (service iptables save) и одной командой отрезать всю сеть (service iptables panic). Как обычно все эти возможности теряются при переходе на systemd.

Т.ч. я, пока, остаюсь при мнении, что задача запуска таки одна.

Да ладно? Неужели не очевидно, что запуск демона httpd отличается от запуска iptables, который вообще не демон?

Задачи мониторинга работоспособности разные

Причем тут мониторинг? Мониторинг — это не задача init-а. С чего это вдруг init должен ей заниматься? Зачем?

Задачи остановки, согласно канонам, должны были бы быть одинаковыми, kill(2).

Согласно каким канонам? Почему, кому и зачем «должны»? Почему именно по kill-у, по kill-у кого? Просто так? А давайте сделаем, чтобы все программы останавливались по хлопку в ладоши, они должны слушать микрофон через пульсаудио и если распознают хлопок — должны останавливаться?

initscripts дают универсальный интерфейс, единый для всех: сервис стартует по команде start, останавливается по команде stop, и для удобства юзера может уметь status, reload и другие. Эта схема проста, удобна и работает для всех. Какие у нее есть недостатки?

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

Если ты умеешь включать телевизор, это еще не значит, что ты должен следить за его деталями и заменять сгоревшие, правда? Точно так же если init умеет включать систему, это еще не значит, что он должен следить за процессами и перезапускать упавшие.

Итого, и инит и системд выглядят _одинаково_ гов^Wкомпромисными реализациями, а демонтулс - кошерным геморроегеном.

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

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

конвертор service-файлов в баш скрипты

Кстати, идея: systemd это вовсе не система инициализации, это domain-specific интерпретатор, на замену обычно используемому sh-у, что-то типа busybox-а с более приспособленным для задачи языком. За счёт специфичности убирается куча bolilerplate кода, который мы видим в initscripts.

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

... если сервисов не больше 4(в линуске чуть больше, порядка 7)... Тебе столько хватает?

С точки зрения init-а у меня всего один сервис initscripts. И да, мне его хватает. :)

man pam_loginuid. Очень нужная параноикам штука.

А, ок. Никогда не приходилось сталкиваться с проблемами из-за loginuid. К тоже же эта «проблема» решена появлением service/invoke-rc.d.

Нет; init 4 или service whatewer или что там с xinetd или svc -d или su - юзер svc -d.

Эта фраза осталась для меня загадкой. Расшифруй ее, пожалуйста.

Помнишь про "... не проще, чем это необходимо"?

Обычно в юниксах проще ­— лучше. Классическая схема была проста, она была лучшей, и, как мы тут выяснили, все ее «проблемы» были решены двадцать лет назад. А systemd — это сложнее, чем любой вменяемый человек вообще мог придумать.

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

Как обычно все эти возможности теряются при переходе на systemd.

Это же глупости

который умеет кучу всего

unix-way, ок

инит выглядит универсальным решением

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

Потому что у леннарта NIH-синдром

Это верное замечание. Но в данном конкретном случае это не так уж и плохо (%

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

Система инициализации это же система, которая должна весь жизненный цикл сервиса обслуживать [...]

С чего это вдруг?

Повар на кухне должен только приготовить мне курицу. Он не должен эту курицу выращивать, не должен ее откармливать, не должен добывать фарфор для тарелок, производить вилки и ножи он тоже не должен. И уж тем более он не должен нести эту курицу ко мне домой, жевать ее там для меня, следить как я ее глотаю, и анализировать то, что я, прошу прощения, высрал после еды. Всё это — не его дело.

Точно также система инициализации должна только запустить программу, остальное — не ее заботы. С чего это вдруг она должна делать что-то ещё? Зачем ей делать то, что другие могут сделать лучше?

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

Как обычно все эти возможности теряются при переходе на systemd.

Это же глупости

Увы, это правда. У тебя ж systemd, открой свои юниты и попробуй найти там эти функции.

который умеет кучу всего

unix-way, ок

Именно! Скрипт iptables не готовит кофе, не содержит http-сервер и не генерирует QR-кодов, он делает только одну вещь — управляет iptables, но делает эту одну вещь хорошо, вплоть до мелочей.

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

Он делает именно то, что должен — предоставляет универсальный интерфейс для запуска и остановки. Он делает одну вещь, зато делает ее идеально. За сколько лет его использования в нем не было найдено ни одной ошибки? ;)

Это верное замечание. Но в данном конкретном случае это не так уж и плохо (%

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

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

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

Это написано в каком то талмуде? Это ваше мнение, что она должна. У NIH инвенторов другое мнение. А у разрабов Андроида - еще одно :D

Скажем спасибо ядру, отделенному от государства, за многообразие мнений и возможностей

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

Увы, это правда. У тебя ж systemd, открой свои юниты и попробуй найти там эти функции.

Их там нет, потому что серьезно за пиление юнитов еще не брались. А функционал systemd соответствующий на месте

Именно! Скрипт iptables не готовит кофе, не содержит http-сервер и не генерирует QR-кодов, он делает только одну вещь — управляет iptables, но делает эту одну вещь хорошо, вплоть до мелочей.

Ну так systemd не готовит кофе, не содержит http-сервер и не генерирует QR-кодов, он делает только одну вещь - управляет жизненным циклом сервисов, но делает эту одну вещь хорошо, вполть до мелочей.

и долбал всех, пока его поделку не приняли.

Что, правда чтоль? :D

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

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

Это возможно, только если система не догрузится до login prompt. А если такое происходит, значит кто-то не запихал OnFailure в default.target

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