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)

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

Раз помог только таймаут, то это косой юнит, или ожидание устройства. Но в случае устройств там таки есть таймауты, так что почти 100%, что подвисший юнит.

Зырь таки в лог:

journalctl -b

Если там ничего нет, значит придется искать подвисший кусок сервиса :D

Есть пара вариантов. Самый простой - стартануть в tmux systemctl start default.target, а во втором инстансе посмотреть systemctl list-jobs

Второй — если это был сервис, то его убили при вываливании в эмердженси. Можно посмотреть убитые сервисы такой нехитрой комбинацией (%

for service in $(systemctl --all -t service --no-legend | awk "{print \$1}"); do [ ! -z "`systemctl --no-pager show -p ExecStart $service | grep status=15`" ] && echo $service ; done

Можно ознакомится с планом выполнения через systemd --test, и сравнить с тем что есть. Лично я бы шел по пути (1)

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

Вообще, в новых systemd (кажется >194) для анализа достаточно из эмердженси почитать/посчитать, если фильтр лог левела конечно правильно настроен

journalctl -b _COMM=systemd
vasily_pupkin ★★★★★
()
Ответ на: комментарий от vasily_pupkin

Ок, согласен. Засунуть после первого ExecStart:
ExecStart=-/sbin/restorecon /etc/ssh/ssh_host_%i_key

Ну ладно, выкрутился. :)

Осталось теперь добавить проверку на файл нулевого размера (в этом случае ключ перегенерируется) и проверку на ранлевел (оригинальный скрипт по stop-у убивает рабочие сессии только в том случае, если это halt или reboot), и только тогда это будет аналог инитскрипта.

То есть вместо одного shell-скрипта мы получили 2-4 юнита?

1 юнит, вообще-то. C N инстансами

Вообще-то уже минимум два (sshd и sshd-keygen). А скорее всего три, потому что в комплекте к systemd идет обычно sshd.socket, и для него тоже придется добавить Before/Required в sshd-keygen, либо делать еще один юнит специально для .socket-а.

Проблемы? Почти юниксвей :D Ты можешь:
1. поотрубать ненужные куски, не правя вендор скрипт
2. добавить хуки не правя вендор скрипт

Не, юниксвей — это когда одна программа делает одно дело. А когда для одного дела приходится писать десяток boilerplate-юнитов — это не юниксвей, это brainfuck. :)

Вся эта лишняя работа по поиску и отлову ошибок, вызванных systemd, так бесит. Скажем обычный человек может подумать, что раз sshd уже запускался, то ключи генерировать больше не надо, и сделает disable для sshd-keygen, а потом будет удивляться, почему sshd перестал стартовать...

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

добавить проверку на файл нулевого размера

Эм. Добавить ConditionFileNotEmpty=!/....

Тут, конечно, повезло, что леннарт насобачил кучу часто встречающихся правил, и если бы его не было, то скорее всего пришлось бы городить скрипт, или переводить его в wants

Вообще-то уже минимум два (sshd и sshd-keygen). А скорее всего три, потому что в комплекте к systemd идет обычно sshd.socket, и для него тоже придется добавить Before/Required в sshd-keygen, либо делать еще один юнит специально для .socket-а.

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

А brainfuck — это писать инитскрипт для нескольких дистров.

проверку на ранлевел (оригинальный скрипт по stop-у убивает рабочие сессии только в том случае, если это halt или reboot)

Не скажу за всю одессу, но рабочие сессии теперь выкорчевывает logind, так что тут не все однозначно. Т.е. stop сессии sshd не убивает. Поубивать сессии можно с loginctl

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

У-у-у, шаман!

Камлай! Камлай шибче!

По мне, так если у <имярек> появился command prompt, этот имярек уже должен быть в состоянии смотреть состояние системных сервисов. Но как видно, прогресс уже не остановить, без графического ивентвьювера имени Катлера уже никуда.

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

Для начала я бы сказал, что, на мой взгляд, в инитскриптах не место операциям, отличным от start|stop. Правильный подход, на мой взгляд — утилки вроде apachectl. Да, тот самый separation of concerns, за который ратуют местные неолуддиты. Впрочем, это и правда удобно, не говоря о том, что это Совсем Другое Дело.

кстати, единственное прочтение man systemctl устранило бы претензии по поводу команды reload (параметр ExecReload в конфиге сервиса). а graceful/configtest/pick_nose/etc реализуются вот так — https://lists.fedoraproject.org/pipermail/devel/2012-June/169411.html

ssh … При переходе на systemd эти возможности были утрачены.

ложь. в арче ключи генерятся. про reload см. выше. именно graceful и configtest реализованы тут — https://lists.fedoraproject.org/pipermail/scm-commits/2012-July/811871.html

позволяет указать параметры для httpd

обычные переменные окружения. EnvFile (или как там его) в зубы и вперёд. остальное — см. выше.

iptables

см. выше.

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

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

initscripts дают универсальный интерфейс, единый для всех … Какие у нее есть недостатки?

про лишние команды я уже упомянул выше. ну и ещё пару:

  • батники. запуск элементарного тупосервиса — от 40 строк шеллскрипта (вот /etc/init.d/i2p — 182 строки boilerplate). я знаю, что можно меньше, да вот кто бы рассказал это maintainerам мейнстримовых дистров, а? inbefore «они тоже тупые, а посему не считается» — типичные ненастоящие шотландцы
  • pidfiles и соответствующий boilerplate в сервисах.
  • cgroups искаропки. 400 процессов какого-нибудь опача не получат больше ресурсов, чем сервер postgres (без специальных указаний). несмотря на «cgroups? вот-вот будут» в openrc, сомнительно, что эта фича там появилась бы иначе, чем по просьбам «фанбоев_systemd».
  • именно из-за обилия boilerplate обработка краевых случаев неконсистентна чуть менее, чем полностью. вот например: запуск инитскрипта непривилегированным пользователем. /etc/init.d/i2p status говорит «You must be root to start this service.» какой такой «start» — я же статус смотрю, не? sudo /etc/init.d/smbd status говорит, что сервис работает, а то же без sudo — говорит, что нет. кому верить? нет, я знаю, почему это происходит (я смотрел), но мне плевать на причины, т.к. на вопрос «зачем такое сделано» вменяемого ответа я вряд ли получу.

ну и хватит пока.

Если ты умеешь включать телевизор

без ненужных и некорректных аналогий что, уже совсем никак?

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

Я ничего не понял, но ты тронул моё сердце :3

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

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

вот и подросло поколение, которое не знает, что такое «batch file». но я вам даже где-то завидую — впереди ещё столько открытий.

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

Зырь таки в лог: journalctl -b

Там:

Oct 28 07:59:30 localhost.localdomain lvm[498]: No volume groups found
[40 секунд тишины]
Oct 28 08:00:06 localhost.localdomain systemd[1]: Job default.target/start ti...
Oct 28 08:00:06 localhost.localdomain systemd[1]: Job default.target/start fa...
Oct 28 08:00:06 localhost.localdomain systemd[1]: Triggering OnFailure= depen...
Oct 28 08:00:06 localhost.localdomain systemd[1]: Job dbus.service/start fail...
Oct 28 08:00:06 localhost.localdomain systemd[1]: Job avahi-daemon.service/st...
Oct 28 08:00:06 localhost.localdomain systemd[1]: Job gdm.service/start faile...
Oct 28 08:00:06 localhost.localdomain systemd[1]: Job systemd-logind.service/...
Oct 28 08:00:06 localhost.localdomain systemd[1]: Job NetworkManager.service/...
Oct 28 08:00:06 localhost.localdomain systemd[1]: Job firewalld.service/start...
Oct 28 08:00:06 localhost.localdomain systemd[1]: Job dbus.socket/start faile...
Oct 28 08:00:06 localhost.localdomain systemd[1]: Job rpcbind.service/start f...
Oct 28 08:00:06 localhost.localdomain systemd[1]: Job rsyslog.service/start f...
Oct 28 08:00:06 localhost.localdomain systemd[1]: Job multi-user.target/start...
...

Что дальше?

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

-ba

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

Ну и lvm отключай :D Походу он и есть подвисший. Что за дистрибутив?

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

Мои скрипты на sh запускались задолго до того, как ты начал писать свои первые поделки для autoexec.bat на ублюдочном диалекте command.com. Надеюсь, новые открытия в лице PowerShell мне не сулят также, как я пережил говняный VBScript host. Зато теперь понятно, кому и почему тут нравится systemd.

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

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

Мои скрипты на sh запускались задолго до того, как ты начал писать свои первые поделки для autoexec.bat на ублюдочном диалекте command.com.

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

дневник с двойкой по английскому

ого, и правда неправильно. спасибо, буду знать.

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

Теперь это выглядит, как попытка пользователя уйти от системы аудита:)

А? Пользователь (без соответствующих привилегий) не может менять loginuid.

И только потому, что init не умеет запускать отдельный сервис без редактирования inittab-а.

Причем тут init? Инит вообще не должен уметь запускать или останавливать сервисы без смены ранлевела, это initscripts добавили такую возможность. А в рамках initscripts редактирование loginuid отлично вписывается в задачу «run init script in as predictable environment as possible» (цитата из man service).

Теоретически можно прикрутить костыль в виде отдельного скрипта init_service:

#!/bin/sh
echo 4294967295 > /proc/$$/loginuid
exec service "$@"
и вместо service httpd restart запускать init_service httpd restart, это тоже позволит решить проблему без переписывания, но на мой взгляд это — костыль, а исправление поведения service — правильное решение проблемы (если она вообще есть).

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

Ага, теперь понятно. Все верно, я считаю глупостью дробить одну задачу на несколько компонентов, поэтом необходимость писать 2-3 юнита (sshd, sshd-keygen и т.д.) для реализации одной задачи (запуска ssh) в systemd мне кажется глупостью.

Но в данном случае речь идет о выполнении похожих, но разных действий. В названном ранее примере их три:
1. Отключение respawn-style демона иксов
2. Отключение initscripts-сервиса
3. Отключение xinetd-сервиса

Логично, что они выполняются разными командами. Удаление файла в midnight commander-е отличается от удаления письма в gmail-овом ящике. Никто ж не требует от midnight commander-а возможности удалять письма в гмейловом ящике? А ведь и то и другое удаление. В чем разница? В том, что удаляются разные сущности. Вот и тут то же самое.

Кстати, в systemd это тоже разные команды (systemctl ... sshd.service и systemctl ... sshd.socket, например). Было бы странно, если бы одна команда стопала или стартовала два конфликтующих сервиса, правда?

значит, что оно было лучшим

*было*

И что, с появлением systemd мир перевернулся, и оно перестало быть лучшим?

Что ты называешь словом «костыль»

Предлагаю «средство компенсации недостаточно полно/правильно реализованной/работающей функциональности».

В баше очень неполно реализована функциональность по редактированию текстовых файлов. она там есть (read, echo), но очень неполная. Можно ли считать в таком случае vim/emacs костылем для баша? Должен ли баш включать в себя vim/emacs, чтобы избавиться от костылей?

man init говорит, что «Its primary role is to create processes», и оно с этой ролью справляется плохо

Точнее «Its primary role is to create processes from a script stored in the file /etc/inittab». Процессы запускает? Запускает. Значит справляется. :)

приходится подставлять костыль rc.

Какое отношение rc имеет к задаче «create processes from /etc/inittab»? Правильно, никакого. Получается, это не костыль. :)

Сами init.d/скрипты [...] являются, скорее, «клеем» между сервисом, rc, системными политиками и пр. настройками.

Это называется «универсальный интерфейс» же. :) Как альса — универсальный интерфейс к звуковухе, клей между программами и оборудованием. Причем интерфейс инитскриптов настолько универсален, что удобен и для rc и для человека.

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

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

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

А? Пользователь (без соответствующих привилегий) не может менять loginuid.

Смысл AUID в том, что после логина его вообще никто не может менять

Ага, теперь понятно. Все верно, я считаю глупостью дробить одну задачу на несколько компонентов, поэтом необходимость писать 2-3 юнита (sshd, sshd-keygen и т.д.) для реализации одной задачи (запуска ssh) в systemd мне кажется глупостью.

Я тут даже не знаю что сказать. У меня sshd как то и без sshd-keygen работает. Значит ли это, что задача делима?

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

добавить проверку на файл нулевого размера

Эм. Добавить ConditionFileNotEmpty=!/....

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

Тут, конечно, повезло, что леннарт насобачил кучу часто встречающихся правил, и если бы его не было, то скорее всего пришлось бы городить скрипт, или переводить его в wants

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

Но вопрос про убивание живых сессий только в случае shutdown-а остается в силе. Плюс один юнит?

stop сессии sshd не убивает. Поубивать сессии можно с loginctl

Дык, можно вообще ничего никогда не убивать, логин сам всех убьет KILL-ом при выключении. Вопрос же был в том, как сделать это корректно, воспроизведя функциональность инитскрипта. :)

По идее это должен быть oneshot-юнит wanted by shutdown. Но как сделать, чтобы он делал start после того как в sshd отработал stop?

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

Хм, тогда у меня тот же вопрос — что считается костылем? Один скрипт /etc/init.d/sshd справлялся с задачей запуска. Один юнит с ней больше не справляется, приходится к нему прикручивать еще два дополнительных юнита. Эти два дополнительных юнита разве не считаются костылем, компенсирующим убогость основного юнита?

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

А brainfuck — это писать инитскрипт для нескольких дистров.

В этом initsctipts не виноваты. У них стандартный интерфейс. И стандарт lsb упрощает написание базовых функций. Все сделано для того, чтобы один инитскрипт работал во всех дистрибутивах. Но апстримные релизы обычно не содержат init-скриптов, и пишут их все равно мейнтейнеры. Поэтому тут ничего не изменилось, раньше у каждого дистра был свой initsctipt, теперь у каждого будет свой systemd-юнит.

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

Смысл AUID в том, что после логина его вообще никто не может менять

Почему никто? Тот, у кого есть CAP_AUDIT_CONTROL — может. А что, есть дистры, в которых рут не может менять loginuid своего процесса?

Я тут даже не знаю что сказать. У меня sshd как то и без sshd-keygen работает.

Тогда откуда взялись ключи для sshd?

Значит ли это, что задача делима?

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

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

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

ExecStart=/bin/rm -f ...

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

Дык, можно вообще ничего никогда не убивать, логин сам всех убьет KILL-ом при выключении. Вопрос же был в том, как сделать это корректно, воспроизведя функциональность инитскрипта. :)

Такую функциональность можно повторить таким скриптом. Засунуть в отдельный отключаемый юнит, да. Можно засунуть и в основной, но это неправильный путь. Запускать с ExecStopPost

for session in $(loginctl list-sessions | awk '{print $1}'); do [ "`loginctl -p TTY show-session $session`" = 'TTY=ssh' ] && loginctl terminate-session $session ; done

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

Хз, вроде тривиально

В этом initsctipts не виноваты.
И стандарт lsb упрощает написание базовых функций.

Спорно.

Но апстримные релизы обычно не содержат init-скриптов, и пишут их все равно мейнтейнеры.

Конечно, какой смысл, если везде все по разному. Тут есть некоторый шанс, что через время все устаканится. Впрочем, поживем - увидим.

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

А что, есть дистры, в которых рут не может менять loginuid своего процесса?

А что, есть в которых может? Какой в этом смысл тогда?

# zgrep IMMUTABLE /proc/config.gz 
CONFIG_AUDIT_LOGINUID_IMMUTABLE=y
# cat /proc/1/loginuid > /proc/self/loginuid 
cat: ошибка записи: Операция не позволяется

# id -u
0
vasily_pupkin ★★★★★
()
Ответ на: комментарий от anonymous

Тогда откуда взялись ключи для sshd?

Я их скопировал со старого таза, который отправил в утиль

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

Для начала я бы сказал, что, на мой взгляд, в инитскриптах не место операциям, отличным от start|stop.

В systemd им тоже не место?

единственное прочтение man systemctl устранило бы претензии по поводу команды reload (параметр ExecReload в конфиге сервиса)

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

graceful/configtest/pick_nose/etc реализуются вот так — https://lists.fedoraproject.org/pipermail/devel/2012-June/169411.html

То есть для управления сервисами одна команда (systemctl), а для плюшек — другая? Смахивает на костыль для systemctl, пытающийся скомпенсировать его кривой дизайн. :)

ложь. в арче ключи генерятся.

Как? Мы тут уже почти две страницы правильный юнит сочиняем, все никак не закончим...

обычные переменные окружения. EnvFile (или как там его) в зубы и вперёд.

Причем тут EnvFile? Как эти переменные потом в юните использовать?

специально для таких как бы демонов предусмотрен тип сервиса «oneshot».

Именно. Это — другой тип сервисов, даже в systemd. Нельзя все сервисы причесать одной гребенкой. Исходное утверждение «задача запуска таки одна» ошибочно. Об этом и речь. :)

initscripts дают универсальный интерфейс, единый для всех … Какие у нее есть недостатки?

про лишние команды я уже упомянул выше.

Лишние несколько команд — это недостаток? А лишняя сотня команд в systemd — это тогда что?

ну и ещё пару:
батники. запуск элементарного тупосервиса — от 40 строк шеллскрипта

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

(вот /etc/init.d/i2p — 182 строки boilerplate)

Э... Ты вообще знаеш, что означает слово boilerplate? Загляни в словарь, что-ли. Или посмотри внимательно на systemd, там ВСЕ юниты — boilerplate, синтаксис у него такой.

pidfiles и соответствующий boilerplate в сервисах

Что в этом плохого? Где недостаток?

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

Во-первых, ulimit-ы в initscript-ах тоже всегда были из коробки. Во-вторых cgroups в initsctipt-ах точно так же есть из коробки, как в systemd. Если хочешь выставить какие-то аттрибуты cgroups — в systemd правишь юнит-файл, а в initscripts правишь initscript. Но, в отличие от systemd, инитскрипт может работать вообще без cgroups-ов. Так что жесткая зависимость от cgroups — это недостаток у systemd, а не у initscripts.

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

Самопротиворечивое утверждение. Boilerplate по определению не может быть в обработке краевых случаев.

какой такой «start» — я же статус смотрю, не?

И что? Где недостаток? Недостаток initscripts в том, что его можно написать неправильно? Так systemd юнит тоже можно написать неправильно. ВСЁ можно написать неправильно, это фатальный недостаток во всем, что можно писать! :) Но причем тут initscripts?

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

ну и хватит пока.

Стой, куда! Ни одного недостатка initscripts ведь так и не было названо. Давай ещё! :)

без ненужных и некорректных аналогий что, уже совсем никак?

В чем «некорректность»? Вообще, аналогия корректна, она же — аналогия. Если бы она не была корректной, то она не была бы аналогией.

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

-ba

http://pastebin.com/eWKCA8uP

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

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

Ну и lvm отключай :D Походу он и есть подвисший. Что за дистрибутив?

Нету там LVM, нечего отклочать. К тому же он все равно Started (Active: active (exited), code=exited, status=0/SUCCESS). Федора.

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

Не вижу связи. Reload — перечитывание конфига (в systemd его вообще нет),

точно такой же. В случае с sshd как раз и нужен reload, потому что меняются настройки, а не неизлечимые проблемы в самом демоне.

а restart перезапуск демона. Почему restart должен убивать живые сессии. Более того, почему stop должен убивать живые сессии?

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

Вот, а теперь представь, что будет в случае с systemd, где баги приходится вылавливать часами, если не неделями, а потом еще уговаривать апстрим, что это баг а не фича, и его надо починить.

Так не должно быть в systemd одноразового кода. Поэтому и ошибок в нем уже сейчас заметно меньше, чем в initscripts.

Любопытно. Например, какие? А на уровне юнита их написать проще?

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

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

Спустя 5 лет пульсаудио, хоть и стал реже глючить, глючит до сих пор. Как и раньше, в случае глюков никто не знает, что с ним делать. И до сих пор он не перегнал альсу по надежности. Почему с systemd должно быть лучше?

пульс никогда не перегонит альзу по надежности просто потому что не отменяет ее, а дополняет. А systemd является прямой заменой initscripts и в отличие от пульса в принципе не делает ничего слишком уж мутного и сверхестественного.

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

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

Как узнать из-за кого сработал таймаут?

Oct 28 08:00:06 localhost.localdomain systemd[1]: Job default.target/start failed with result 'timeout'.

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

Федора.

Не представляю, что они там могли намутить. Это rawhide, или что-то со старым systemd? Вывали на pastebin systemd --test --system --unit=default.target, полный journalctl -ba в resq шелле и

for service in $(systemctl --all service --no-legend | awk "{print \$1}"); do systemctl --no-pager show -p Id -p ExecStart $service; done
vasily_pupkin ★★★★★
()
Ответ на: комментарий от vasily_pupkin

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

Тогда на всех livecd будут одни и те же ключи. :) Это — не хорошо. :)

Такую функциональность можно повторить таким скриптом. Засунуть в отдельный отключаемый юнит, да. [...] Запускать с ExecStopPost

Не... Его суть не в том, чтобы убить все сессии, а в том, чтобы сделать это только при shutdown-е, но не на обычном stop-е. Как сделать так, чтобы он срабатывал только если stop sshd делается во время shutdown-а?

Хз, вроде тривиально

Мне совершенно не кажется очевидным, что отключение sshd-keygen при работающем sshd должно отключить и sshd тоже. :)

Конечно, какой смысл, если везде все по разному. Тут есть некоторый шанс, что через время все устаканится. Впрочем, поживем - увидим.

Дык, в инитскриптах везде все одинаково. Стандарт же. Но все равно init-скрипты обычно не пишут.

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

А что, есть в которых может?

# zgrep LOGINUID /proc/config.gz
gzip: /proc/config.gz: No such file or directory
# grep LOGINUID /boot/config*
#
либо:
# grep LOGINUID /boot/config*
# CONFIG_AUDIT_LOGINUID_IMMUTABLE is not set
#

Какой в этом смысл тогда?

А какая разница? До systemd рут мог выставить любой loginuid, записав uid в /proc/self/loginuid. В systemd рут может выставить любой loginuid, запустив сервис через systemd... и записав uid в /proc/self/loginuid.

Что изменилось? С точки зрения параноиков?

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

Не... Его суть не в том, чтобы убить все сессии, а в том, чтобы сделать это только при shutdown-е, но не на обычном stop-е. Как сделать так, чтобы он срабатывал только если stop sshd делается во время shutdown-а?

Вообще это не нужно, т.к. shutdown и так стопнет сессии. Но если очень хочется, то делается сервис shutdown-ssh-sessions.service, туда пихается в Install WantedBy=shutdown.target и делается enable. Если очень очень хочется что бы это запускал имеенно sshd при останове (хотя это полный бред), то пихается ExecStopPost=/usr/bin/systemctl start shutdown-ssh-sessions.service, а в shutdown-ssh-sessions.service добавляется Requisite=shutdown.target

Мне совершенно не кажется очевидным, что отключение sshd-keygen при работающем sshd должно отключить и sshd тоже. :)

Э?

Дык, в инитскриптах везде все одинаково. Стандарт же. Но все равно init-скрипты обычно не пишут.

Не одинаковы средства управления выводом на экран, управления процессами итд. Они везде разные

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

А какая разница?

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

vasily_pupkin ★★★★★
()
Ответ на: комментарий от anonymous
> cat /etc/systemd/system/smartfail.service      
[Unit]
Description=Push some diagnosis to logs

[Service]
Type=oneshot
StandardOutput=journal
ExecStart=/usr/bin/systemctl list-jobs
ExecStart=/usr/bin/systemctl start emergency.target
 > systemctl show -p OnFailure default.target --no-pager
OnFailure=smartfail.service

Попробуй кстати так. Я вот не уверен, что тут не будет рейсов, но попробовать стоит

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

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

Ничего не будет. Пульса, вроде, стартует независимо от наличия синков. Звук, просто, направится в /dev/null.

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

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

Ясно, что из-за зависимостей, вопрос — из-за которой? Как узнать, какая зависимость вызвала таймаут?

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

Казалось бы, апстрим. :)

Это rawhide, или что-то со старым systemd?

Это почти релиз. То ли альфа то ли бета F18.

systemd --test --system --unit=default.target

Don't run test mode as root.

полный journalctl -ba в resq шелле и

Это и был полный, начиная с Journal started. Предыдущая строка в логе: «systemd-journal: Journal stopped» из initramfs.

for service in $(systemctl --all service --no-legend | awk «{print \$1}»); do systemctl --no-pager show -p Id -p ExecStart $service; done

# systemctl --all service --no-legend
Unknown operation 'service'.

Но если из systemctl --all --no-legend вручную вырезать все, кроме service-ов, то остается: http://pastebin.com/vJZCxSxm

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

ExecStart=/usr/bin/systemctl list-jobs Попробуй кстати так.

А этого не хватит?

# systemctl list-jobs
   5 local-fs.target           start           waiting
  35 systemd-...d-load.service start           waiting
  41 systemd-...-setup.service start           waiting
  46 plymouth...-write.service start           waiting
  40 systemd-...-flush.service start           waiting
  19 systemd-...unt-fs.service start           waiting
  17 systemd-fsck-root.service start           waiting
  20 local-fs-pre.target       start           waiting
 102 systemd-...nlevel.service start           waiting
  61 fedora-a...l-mark.service start           waiting
  64 fedora-configure.service  start           waiting
  66 fedora-a...elabel.service start           waiting

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

Если это был полный лог, то там точно бодяга с этим fedora-storage-init. Там же больше ничего не запускается

systemctl mask fedora-wait-storage.service fedora-storage-init-late.service fedora-storage-init.service

Перед этим можно попробовать

Новый релиз systemd 195 (комментарий)

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

Они все в waiting. Должно же что-то быть в running >_<

--full надо не забыть добавить, что бы выхлоп полный был

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

точно такой же. В случае с sshd как раз и нужен reload, потому что меняются настройки, а не неизлечимые проблемы в самом демоне.

Емнип, некоторые настройки нельзя поменять reload-ом, например, порт.

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

Во-первых, так не считает даже systemd. Во-вторых, раньше он так считал, но потом оказалось, что тогда при обновлении системы по ssh портится база данных пакетов (казалось бы, причем тут systemd), пришлось прикручивать костыль в виде pam_systemd (и заодно прибивать pam гвоздями к sshd). В-третьих, если бы даже и считал, в общем случае это невозможно, нельзя сделать так, словно его вообще не запускали. Сервис мог внести самые разнообразные изменения в систему (например, залить файлы на dropbox), и универсального способа отменить их просто нет.

Так не должно быть в systemd одноразового кода.

А как же пол сотни переписанных-на-си-баш-скриптов вроде systemd-cat, systemd-diff, systemd-sleep...?

Поэтому и ошибок в нем уже сейчас заметно меньше, чем в initscripts.

Пока что в нем ошибок заметно больше. Случаев, когда машина не грузилась бы (или не выключалась) с инитскриптами я не помню, наверное, уже лет... хм... вообще не помню. Очень-очень долгую загрузку sysvinit из-за кривых записей в fstab-е помню, чтоб не стартовали иксы помню, а чтоб вообще не доходило до консоли, такого не помню. Зато с systemd это сплошь и рядом. И не смотря на то, что прошло уже 2 года, некоторые эпичные баги вылазят до сих пор. Например, почему бы не прогнорировать все эти Before/After, ведь система тогда так быстро грузится...

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

Вообще это делается командой runuser, но, чтобы не изобретать велосипед, есть start_daemon из LSB.

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

Взаимоисключающие параграфы?

Кстати, не сильно-то он высокоуровневый. Баш местами даже более высокоуровневый — в нем нормальные условия и циклы есть, а тут какое-то извращение (ConditionNull=no).

А systemd является прямой заменой initscripts и в отличие от пульса в принципе не делает ничего слишком уж мутного и сверхестественного.

У него — свои шаманства. Вон, система виснет при загрузке, и фиг поймешь, где и почему. В любых инитскриптах это отлаживается на раз-два: отключаем параллельный запуск и смотрим, на какой строке повисли, всё. А тут...

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

OnFailure=smartfail.service Попробуй кстати так. Я вот не уверен, что тут не будет рейсов, но попробовать стоит

Так даже в консоль не вываливается, висит как и раньше. Но если заменить StandardOutput=journal на StandardOutput=tty, то list-jobs таки видно: http://pastebin.com/5XVVGawZ

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

Что-то вообще какая-то наркомания (%

Это какой то странный лог. Судя по нему, у тебя как минимум должен был стартануть/быть виден gdm. Вообщем, там весьма немного того, что могло завалится. Посмотри юниты в running на предмет ExecStart.

Сделай sort -rnk 1, сверху вниз претенденты.

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

Что-то вообще какая-то наркомания (%

%)

Это какой то странный лог. Судя по нему, у тебя как минимум должен был стартануть/быть виден gdm.

Уверяю, его не видно.

Вообщем, там весьма немного того, что могло завалится. Посмотри юниты в running на предмет ExecStart.

Дык, все ExecStart-ы есть тут, что в них искать?

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

И я не понимаю, почему столько внимания уделяется тому, что напихано в pid1

Потому что pid1 должен работать __всегда__. Если его избыточно усложнить, ты получишь множество точек отказа в самом главном, с точки зрения ОС, процессе.

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

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

Не замечаешь разницы между ребутом, который восстанавливает весь контекст заново (хотя возможно базы уже безвозвратно потеряны) и тем, что предлагает Поттеринг — перезапуском __процесса__, возможно с уже поломанным контекстом.

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

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

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

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

В systemd им тоже не место?

да, не место.

Ее много, она постоянно меняется

нужно знать, что поменялось? исходники есть в интернетах, диффы можно прямо из cgit смотреть (вроде как).

То есть для управления сервисами одна команда (systemctl), а для плюшек — другая?

да, для legacy — другая.

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

ну, я поставил пакет openssh и оно себе крутится под неправильным юнитом с socket activation

Как эти переменные потом в юните использовать?

man systemd.unit /ExecStart<ENTER>, третий абзац

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

можно причесать 99%, а остальные пускать скриптами

Лишние несколько команд — это недостаток?

нет, это «команды никуда не делись, поздравляю вас соврамши»

Даже будучи длинным, он остается простым и понятным.

Не остаётся, не надо. Чтобы написать инитскрипт, с нуля нужно раскурить гораздо больше информации, чем по SD. сначала LSB, затем шелл (ну его все знают, ладно), затем техники камлаbest practices написания как инитскриптов вообще, так и в конкретном дистре. Ещё, правда, есть вариант побыстрее — взять другой инитскрипт, preg_replaceом заменить путь к бинарнику и чинить симптоматически; это симптом профнепригодности и в итоге всё равно приводит к отстреленной ноге.

ну и да, батники не поддаются статическому анализу.

Ты вообще знаеш, что означает слово boilerplate?

надцать батников, различающихся только именем и путём к бинарнику. сплошь и рядом такое.

pidfiles

они хрупкие. стёр pidfile — и всё, процесс потерян для инитскрипта. плюс шаблонный кусок кода их поддержки в сервисе.

ulimit-ы в initscript-ах тоже всегда были из коробки

и кто ими пользовался?

cgroups в initsctipt-ах точно так же есть из коробки

и кто ими пользуется «искаропки»? openrc и его полтора разработчика?

жесткая зависимость от cgroups

да, это же так бесчеловечно заставлять людей пользоваться ядром >2.6.24

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

если только этот код не скопипастили. в лучших традициях, так сказать.

Недостаток initscripts в том, что его можно написать неправильно?

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

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

системд, значит, панацея

Ты сказал.

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

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

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

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

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

Так что я не вижу особого смысла отделять pid1 от супервизора. Это усложнит систему и не решит проблем с устойчивостью.

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

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

Не «ломают», а «не пишут дальше». Но с таким количеством обожателей sysvinitу-то такая судьба точно не светит.

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

У меня больше вопросы к дизайну, чем к самому факту создания SD.

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

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

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

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

P.S. если сильно хочется, то мне не лень собрать систему и с систем-д, чтобы продемонстрировать там конкретные вопросы, только давайте, тогда уже настанет моя очередь выставлять счёт? :)

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

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

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

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

Ну, это как с конфигами, сертификатами итп. Ты же не предлагаешь генерировать конфиги на первом старте?

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

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

Понятия не имею. Если по тех требованиям его там быть не должно, почему он там должен быть?

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