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)
Ответ на: комментарий от AVL2

Это вопрос. Никто не мешает иметь логгирующий и бебиситтерный процессы сущностями, отдельными от pid=1. Иначе получается как у Молнара, что без ядерного логгера в логи pid=1 и не посмотришь...

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

В плане централизации сведений о временных файлах - вполне себе нужная штука. Использует её отдельная утилита из поставки systemd, со своим юнитом. Который соответственно можно отключить/заменить. Можно написать свой костыль для крона который будет использовать эти сведения, например

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

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

на стопе сервиса никак не? или ради F,D,r,R, если так, то можешь посмотреть, какие юниты это используют?

ваще костыль какой-то..

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

Капитан сообщает, что pid 1 является корнем дерева процессов. pid 1 невозможно убить. Если pid 1 самоубьётся, система зависает с паникой ядра.

У меня актуальный вопрос: как человек, не знакомый с базовыми принципами устройства Unix и Linux, может дискутировать о системе инициализации?

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

Причем тут стоп сервиса? Например устаревшие кеши man. Оно не обязательно привязано к сервису. Это как правило в cron, типа logrotate.

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

повторю вопрос, можешь ли ты посмотреть, какие сервисы предоставляют tmp.d файлы с правилами F,D,r,R?

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

Я не совсем понимаю что ты хочешь, так что вот:

 > find /etc/tmpfiles.d /usr/lib/tmpfiles.d/ -type f | grep -v keep | xargs equery b
 * Searching for /etc/tmpfiles.d/postgresql.conf,/etc/tmpfiles.d/pcscd.conf,/etc/tmpfiles.d/screen.conf,/etc/tmpfiles.d/nm-dispatch.conf,/usr/lib/tmpfiles.d/gentoo-run.conf,/usr/lib/tmpfiles.d/systemd.conf,/usr/lib/tmpfiles.d/tmp.conf,/usr/lib/tmpfiles.d/mysqld.conf,/usr/lib/tmpfiles.d/x11.conf ... 
sys-apps/systemd-194 (/usr/lib/tmpfiles.d/gentoo-run.conf)
sys-apps/systemd-194 (/usr/lib/tmpfiles.d/tmp.conf)
sys-apps/systemd-194 (/usr/lib/tmpfiles.d/x11.conf)
sys-apps/systemd-194 (/usr/lib/tmpfiles.d/systemd.conf)
sys-apps/systemd-units-3 (/usr/lib/tmpfiles.d/mysqld.conf)
> grep "^[FDrR]" -R /usr/lib/tmpfiles.d/ /etc/tmpfiles.d/
/usr/lib/tmpfiles.d/systemd.conf:F /run/utmp 0664 root utmp -
/usr/lib/tmpfiles.d/systemd.conf:r /forcefsck
/usr/lib/tmpfiles.d/systemd.conf:r /forcequotacheck
/usr/lib/tmpfiles.d/systemd.conf:r /fastboot
/usr/lib/tmpfiles.d/systemd.conf:F /run/nologin 0755 - - - "System is booting up."
/usr/lib/tmpfiles.d/x11.conf:r /tmp/.X[0-9]*-lock
vasily_pupkin ★★★★★
()
Ответ на: комментарий от geekless

Нет. Я просто не понимаю ход твоих рассуждений, и прошу тебя пояснить. Я видимо что-то упускаю. Можешь подробно расписать события приводящие к kernel panic?

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

supervision service не обязать быть pid-1, хотя желательно, чтобы он был родителем сервисов.

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

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

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

плюс потенциально опасные вещи такие как клиент dbus находятся в pid-1.

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

Сегфолт в pid 1 приводит к панике ядра. Поэтому pid 1 должен быть простым и отлаженным как хорошая винтовка.

А у нас тут вместо простоты какой-то винегрет с dbus и поэтессами.

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

Можешь код ядра на Си. Но вообще мне интересно, почему сегфолт в pid 1 приводит к панике ядра ))

vasily_pupkin ★★★★★
()
Ответ на: комментарий от vasily_pupkin
/usr/lib/tmpfiles.d/x11.conf:r /tmp/.X[0-9]*-lock


Remove a file or directory if it exists. This may not be used to remove
non-empty directories, use R for that.

ух тыж красота..

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

что мешает после SIGSEGV попытаться продолжить работу?

С потерей контекста исполнения? Оригинально. Вернуться из обработчика SIGSEGV ты не сможешь, ибо это UB. Куда передавать управление будем?

Или ты предложишь сделать exec в новую копию systemd? :}

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

процесс его к чертям проигнорить может

Игнорировать можно только если сигнал сгенерирован вызовом kill(). В ином случае, игнорирование SIGSEGV — UB.

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

Или ты предложишь сделать exec в новую копию systemd?

Ну все остальные сервисы systemd же так перезапускает. ;)

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

ман читать умею, но в случае vasily был именно kill.

Кэп подсказывает, что ошибка сегментирования и посылка аналогичного сигнала при помощи kill — это «два разных человека». На что я Василию и намекнул, после чего тот включил дурку.

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

вы это vasily объясните, а то он какие-то выводы на основе данного «опыта» делает.

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

я то понимаю..

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

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

Я пропустил всю драму, а перечитывать лень. Я правильно понимаю, что оно чистит временные файлы раз в сутки? «Аптайм больше 12 часов не нужен»? :}

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

не, там всё нормально в итоге. Суть проблемы: есть tmpd файлы описывающие: а). какие каталоги и с какими правами нужны, напр для screen каталоги в /run б). добавляющие костыли, типа truncate file, удалить каталог и файл (тоже можно использовать для убирания локов, но уже странно). Так вот systemd перезапускает выполнение этих файлов раз в день, вопрос, зачем это надо и кем реально используется. Ответ от v_s: для чисти кешей.

После прочтения Поттерингоблога я нашёл, что чистится только то, у чего есть параметр age, который в свою очередь применим к «The age field only applies to lines starting with d, D and x», т.е. создание директории если нет, создание директории и её очистка и отмена очистки по age. При этом про поведение других опций при повторном запуске ничего не сказано (UB). Т.е. всё не совсем плохо.

Хотя вопрос нафига это надо у меня как-то не сильно угас.

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

Если бы ты написал - эгегей, после сегфолта systemd станет неюзабельным, - я бы с тобой может быть согласился. Но kernel panic это перебор. В обоих инитах (sysvinit,systemd) есть краш хендлеры, что очевидно.

По поводу kill — мне не хотелось среди рабочего дня делать свой systemd неюзабельным, я и так знаю что в панику он не свалится :3

# gdb -p 1
(gdb) info registers esp
esp            0xbfe7f844	0xbfe7f844
(gdb) set {int}0xbfe7f844=0
(gdb) set {int}0xbfe7f840=0
(gdb) set {int}0xbfe7f830=0
(gdb) set {int}0xbfe7f820=0
(gdb) set {int}0xbfe7f810=0
(gdb) quit
A debugging session is active.

	Inferior 1 [process 1] will be detached.

Quit anyway? (y or n) y
Detaching from program: /usr/lib/systemd/systemd, process 1

# journalctl -p 2 -b --no-pager
-- Logs begin at Thu, 2012-10-04 12:17:24 EEST, end at Fri, 2012-10-26 15:43:41 EEST. --
Oct 26 15:41:17 CLU kernel: systemd[1]: segfault at 1ac ip b7738e90 sp bfe7f860 error 4 in systemd[b772...de000]
Oct 26 15:41:17 CLU [2284]: Process 2283 (systemd) dumped core.

# gdb -p 1
(gdb) bt
#0  0xb76fe424 in __kernel_vsyscall ()
#1  0xb750d6c6 in __pause_nocancel () at ../sysdeps/unix/syscall-template.S:82
#2  0xb7793e75 in freeze () at src/shared/util.c:4061
#3  0xb7732e8b in crash (sig=11) at src/core/main.c:185
#4  <signal handler called>
#5  manager_loop (m=0xb8ca2bd8) at src/core/manager.c:1432
#6  0xb772ffb1 in main (argc=1, argv=0xbfe7fe44) at src/core/main.c:1719

Пишу с горящего танка )

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

Если бы ты написал - эгегей, после сегфолта systemd станет неюзабельным, - я бы с тобой может быть согласился. Но kernel panic это перебор.

Ну удали какую-нибудь из зависимостей systemd и перезапусти машину, например. Получишь kernel panic в лучшем виде.

В обоих инитах (sysvinit,systemd) есть краш хендлеры, что очевидно.

Не менее очевидно, что systemd именно что «станет неюзабельным» после выполнения хэндлера. Хотя когда я написал именно это, кто-то тут мне порывался ткнуть носом в сорцы sysvinit — какие же сокровища духа можно там обнаружить, теряюсь в догадках.

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

Ну удали какую-нибудь из зависимостей systemd и перезапусти машину, например. Получишь kernel panic в лучшем виде.

Будто бы удалив какую-нибдь зависимость /sbin/init результат не будет таким же.

Хотя когда я написал именно это

Ну, написал ты не именно это, и не мне, и вообще после получасового троллинга

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

с таким подходом можно бед натворить

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

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

Существуют сервисы, часовой простой которых стоит дороже, чем 200 минутных.

Кого увольняем?

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

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

Мне интересно не «что», а «зачем». Для противодействия какой ситуации реализуется такая защита? Никто ж не будет ломать сервер только для того, чтобы насрать в сислог и уйти. Подделку каких записей таким образом пытаются предотвратить?

Но - для параноиков надо, да. ;-)

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

Нашел свой комент с репостом: The Journal: жизнь после syslog (комментарий)

Эх, и там тоже не написано, зачем это надо...

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

Почему на такой сервер не поставить daemontools

out of context. Утверждалось, что надёжный способ убивать/запускать программы на сервере нужен. какой - малосущественно. Но(раз уж холивар начался) почему это не должен быть systemd, кроме того, что он не такой как раньше?

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

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

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

Из-за этих cgroups-ов пришлось городить другие костыли. Пример: что будет, если в systemd перезапустить сервис sshd? Правильно, вместе с ним умрут все ssh-сессии. А если перезапуск делался по ssh, то все будет еще хуже, потому что перезапускащего тоже убьют, и sshd вообще не запустится.

До systemd этой проблемы не было, sshd привычно перезапускали по ssh даже не думая, что что-то поломается. И тут «внезапно» вылез баг. Что сделал Леннарт? Он добавил еще один костыль (модуль pam_systemd, кажется), который каждую ssh-сессию сам переносит в отдельную группу, чтобы они не умирали вместе с sshd.

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

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

Утверждалось, что надёжный способ убивать/запускать программы на сервере нужен. какой - малосущественно.

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

Там, где нужен тупой respawn, как для getty, есть... respawn, причем он есть даже в классическом sysvinit. Тем, кому нужны уникальные обработки остановки/запуска, написаны такие обработчики (вспоминаем mysqld_safe, который, кстати, был поломан в systemd). Для каких-то более-менее универсальных способов есть daemon tools. Наконец можно тупо написать bash -c «while true; do /path/to/my/binary; done» и это тоже будет его перезапускать.

Море способов. Они были до systemd и никуда не делись после его появления. Каждый мог выбрать наиболее удобный для себя способ. Так почему теперь, с появлением systemd все должны бросить привычные удобные инструменты и мучаться с этим убожеством?

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

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

Или вопрос в том, почему бы не добавить в systemd и эту фичу тоже? Ну, в целом, почему бы и нет. А еще на сервере часто нужны текстовые редакторы, давайте их тоже включим в состав systemd. А еще на серверах часто встречается http+php, давайте и их тоже в systemd реализуем. Тем более, что http-сервер в его составе уже есть...

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

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

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

Море способов. Они были до systemd и никуда не делись после его появления.

Так почему теперь, с появлением systemd все должны бросить привычные удобные инструменты и мучаться с этим убожеством?

Отличный вопрос! Действительно, почему?

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