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

При автоматическом перезапуске скайпа

Я ж не системным истансом systemd его мониторю, а тем который в пользовательской сессии.

Я правильно понимаю проблему? Скайп часто падал, и надо было сделать, чтобы он автоматически перезапускался, так? Обычно это делается одной строкой вроде:

while true; do skype; done

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

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

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

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

Он уже содержит http-сервер, генерирует QR-коды, а единственную вещь, которую он должен делать — управление жизненным циклом сервисов — он делает хуже, чем это делали initscripts, и большую часть возможностей initscripts он не поддерживает by design.

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

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

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

Угу, он кричал «УМВР» и хотел использовать его по-дефолту еще в Fedora14, через несколько месяцев после своего первого анонса о systemd. Не смотря на то, что у него тогда даже базовые фичи, вроде «shutdown» не работали. Его тогда заплевали, но он не унимался до тех пор, пока systemd не сделали дефолтным в Fedora15, работа в редхат сделала свое дело. Хотя shutdown у него все равно не работал.

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

Для сравнения, а как это сделать в systemd?

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

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

Он уже содержит http-сервер, генерирует QR-коды

Он - кто? systemd-пакет? Да, возможно. Зависит от билда. systemd-процесс? Нет, не содержит

большую часть возможностей initscripts он не поддерживает by design

Например?

Угу, он кричал «УМВР»

от

долбал всех

отличить сможешь? :D

Что - это?

> cat ~/.config/systemd/user/skype.service 
[Unit]
Description=Skype client
BindsTo=network.target
Wants=dbus.socket
Requires=pulseaudio.service
Requisite=unlimited.target
After=dbus.socket network.target pulseaudio.service
StopWhenUnneeded=yes

[Service]
ExecStart=/opt/bin/skype
TimeoutSec=10
Restart=always

[Install]
WantedBy=network.target

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

Че, правда?!

Ага. Проверено минуту назад, `service sshd restart` работает через ssh и не обрывает сессию. Не помню, чтобы с этим были какие-то проблемы. Разве что какой-то упоротый мейнтейнер написал init-скрипт, который делает restart методом `killall sshd`.

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

Какой дистрибутив? Можно глянуть на initscript?

PS: Да, кстати, initscript еще рулят тем, что даже если мейнтейнер был встельку пьян и написал бред в initscript, то баг легко найти и исправить. Найти и исправить ошибку в systemd практически нереально. Вот у меня при загрузке systemd иногда виснет, а иногда нет. Как это исправить, куда копать?

Как это исправить, куда копать?

Посмотреть в лог?

Гражданин, покажи как журналд запустить без системд.

Эх, тут бы хоть systemd без журнала запустить...

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

Мне кажется, ты плохо смотрел. В каждом из них: сначала идёт #!/bin/sh, пачка комментариев для разных целей, чтение /etc/sysconfig/конфига, case $1 in ..., (?вероятно - не помню)проверка текущего состояния(запущен/остановлен), проверка возможности запуска(наличие конфига и т.п.), наложение ограничений безопасности(chroot/ulimit/runuser/ и т.п.) запуск одного или нескольких процессов, проверка exit status-а, вывод его и описания текущей операции в человекочитаемом виде,создание/удаление pid/lock файлов. Отличия состоят в: 1. названиях конфигов/процессов и параметрах последних - не говори мне, что это существенное отличие, 2. иногда - запуска нескольких дополнительных программ для создания чего-то - я бы сказал, что это нужно не при старте системы делать.

По мне, так это соответствует слову «одинаково». Да, httpd отличается от iptables только тем, что последний живёт в ядре и загружается on-demand через какой-нибудь modprobe.

Согласно каким канонам

Ты забыл, как в unix-е предполагалось доставлять процессам сообщения?

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

Точнее: initscripts - это костыль, прячущий отличия в деталях управления подсистемами от оператора. С чего, вдруг, замена этого костыля должна вызывать такую бурю эмоций мне непонятно.

Какие у нее есть недостатки

Помимо огромного количества bolierplate кода, как и всякая попытка унификации интерфейса, initscripts прячет какие-то возможности; скажем, мне приходится использовать >4х initscript-ов с особенными параметрами, т.к. управляемые системы «неканонически» управляются (без подробностей, т.к. запрещено политикой). Т.ч. то, что в systemd тоже что-то не так работает меня не напрягает; по правде говоря, dbus, кажется, умеет доставлять достаточно информации, чтобы любое расширение уложилось; это же не kill(2) с его 60 сообщениями на все случаи жизни.

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

Ты хотел сказать, «если инит умеет запускать процессы, это ещё не значит, что он должен уметь запускать упавшие процессы». На что я должен заметить, что 1. init это уже умеет, умел делать с самого начала, и делает сейчас (grep respawn /etc/inittab). 2. а почему бы и нет? зарплата init-а от этого же не зависит. 3. init не запускает остальные процессы (скорее всего) именно потому, что ему не хватает умения делать это в правильном порядке/с правильными задержками, останавливать их по одному а не скопом, ну и т.п. Эти ф-ии вынужнено вынеслись в initscripts, а потом к ним пришлось прикручивать всякие demontools-ы.

и все это ради чего

получается, ради того, чтобы убрать пару ненужных костылей.

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

Это sysvinit умеет и без него.

Сокращение количества скриптов и возможность в ряде ситуаций обойтись без них - побочный эффект

Как это? Потеря части привычных и удобных функций — это побочный эффект базовой функциональности? А почему в sysvinit управление последовательностью вызовов не привело к потере функций, а в systemd привело? Автор systemd — говнокодер?

Он - кто? systemd-пакет? Да, возможно. Зависит от билда. systemd-процесс? Нет, не содержит

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

Потеря части привычных и удобных функций

Каких же?

Не содержит, но зависит от журнала, который их содержит

Журнал их тоже не содержит >_<

не патча его

Да, этот фокус не пройдет

Это sysvinit умеет и без него.

Спорно, но допустим. И что?

Что - это?

cat ~/.config/systemd/user/skype.service

Ага, было жутко интересно посмотреть, насколько это «проще» по сравнению с «while true». :)

Ну, зато теперь мне не надо запускать/останавливать его руками. Есть сеть - есть скайп, нет сеть - нет скайп. Надо экономить електричество - есть/нет сеть — скайпа нет. Итп.

Кстати, запущенные с while:; true сервисы очень удобно убивать (p)kill(all)'ом :]

насколько это «проще» по сравнению с «while true».

Теперь добавь к while true умение не пожирать ресурсы при удалении/порче запускаемой программы, адекватную реакцию на на отсутствие сети,аудио и что ещё ему нужно, умение правильно останавливаться, и тогда уже можно сравнивать. Я такое делал; получается много десятков строк. Т.ч. проще.

Как это исправить, куда копать?

Посмотреть в лог?

Пожалуйста, [скриншот], куда дальше смотреть?

Теперь добавь к while true умение не пожирать ресурсы при удалении/порче запускаемой программы

А зачем? Если я запускаю скайп, то я точно знаю, что он есть и не испорчен. Хотя, если так принципиально надо: while sleep 1; do ... done

адекватную реакцию на на отсутствие сети,аудио и что ещё ему нужно

while sleep 1; do ... done

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

while sleep 1; do ... done

Я такое делал; получается много десятков строк.

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

Это решение простое, понятное и надежное. Оно будет работать, если вместо пульса у меня альса или OSS. Оно будет работать, если сеть настроена статически, а не networkmanager-ом. Оно тупое, как бревно, и работает всегда.

Потеря части привычных и удобных функций

Каких же?

Например, этих

Журнал их тоже не содержит >_<

Но содержит та программа, которая этим журналом заведует. А systemd зависит от этой программы. Что за детские придирки? :)

Это что, opensuse? (%

Судя по тому, что у тебя там lvm2, я и так уже догадываюсь с чем зависон.

В любом случае, позырить в лог можно из emergency.target (или с init=/bin/sh). Что-бы туда выпадать автоматом — засунуть OnFailure=emergency.target в default.target

«проблема» решена появлением service

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

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

(положим, это redhat): xdm останавливается через init [^5]. sshd - через service sshd stop, какой-нибудь rsyncd - service xinetd stop; запущенное daemontools-ом - svc что-то-там; добавь к этому разные sudo для полной картины.

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

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

Например, этих

http://en.gentoo-wiki.com/wiki/Systemd#iptables

# cat /etc/systemd/system/sshd-keygen\@.service 
[Unit]
Description=Generate SSH keys (%i algo), if not present
ConditionPathExists=!/etc/ssh/ssh_host_%i_key
Before=sshd.service

[Service]
Type=oneshot
ExecStart=/usr/bin/ssh-keygen -t %i -f /etc/ssh/ssh_host_%i_key -N ''

[Install]
RequiredBy=sshd.service

# systemctl enable sshd-keygen@rsa.service
# systemctl enable sshd-keygen@dsa.service
# systemctl enable sshd-keygen@ecdsa.service

Апача не держу, извини

Но содержит та программа, которая этим журналом заведует. А systemd зависит от этой программы. Что за детские придирки? :)

Ну, программа которым этим журналом заведует называется systemd-journald, и этого не содержит. Программа которая содержит HTTP сервер называется systemd-gatewayd или как то так. Программа которая может содержать QR-коды называется journalctl, и занимается чтением/выводом лога (которого вообще может не быть при включенном форвардинге в syslog и выключенном journal). Ты же понимаешь, что это не означает что в «без них он работать не может», я надеюсь?

Я решаю проблему из реальной жизни

толсто.

AFAIR 90% копипейст,

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

Мне кажется, ты плохо смотрел. [...]

Э... Открой еще раз мое сообщение, там каждый скрипт — это ссылка. Кликни на них и посмотри, сколько процентов там копипаста?

По мне, так это соответствует слову «одинаково».

Твое представление соответствует слову «одинаково», но оно не соответствует действительности. Посмотри в реальные скрипты и сравни. :)

Ты забыл, как в unix-е предполагалось доставлять процессам сообщения?

Нет. Но я не понимаю, какое это отношение имеет к запуску и остановке процессов. Откуда вдруг взялся «канон», согласно которому любой сервис должен останавливаться kill-ом?

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

Точнее: initscripts - это костыль, прячущий отличия в деталях управления подсистемами от оператора.

«Костыль, прячущий отличия в деталях управления подсистемами от оператора» и называется универсальным интерфейсом. Иначе получается, что ядро — это такой костыль, который прячет от программ отличия в управлении оборудованием. libc — это такой костыль, который прячет от программ отличия в реализации стандартных функций. А POSIX — это такой офигенно-глобальный набор костылей. :) Да?

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

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

Какие у нее есть недостатки

Помимо огромного количества bolierplate кода [...] мне приходится использовать >4х initscript-ов с особенными параметрами [...] то, что в systemd тоже что-то не так работает меня не напрягает

Что за бред? Вопрос был, какие у initscript-ов есть недостатки, а ты мне ответил что-то вроде «у меня тут есть такие хреновые инитскрипты, что systemd по сравнению с ними не так уж и плох». Я не понимаю, в каком же месте тут недостаток у initscript-ов?

И, кстати, кто мешает написать initscript в рамках стандартного интерфейса? Это ж не юнит, где нет выбора и приходится копаться среди нескольких сотен опций.

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

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

Нет. «если init умеет включать систему, это еще не значит, что он должен следить за процессами и перезапускать упавшие». Именно в такой формулировке.

1. init это уже умеет

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

2. а почему бы и нет?

Потому что другие сделают это лучше него. Программа должна делать одну вещь, но делать ее хорошо. Неужели этот простой принцип надо объяснить? Если надо, то я могу объяснить, но неужели правда надо?

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

Нет, просто потому, что это — не его задача. Никаких других скрытых причин для этого нет.

получается, ради того, чтобы убрать пару ненужных костылей.

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

Судя по тому, что у тебя там lvm2, я и так уже догадываюсь с чем зависон.

Там нет LVM. Оно зависло после LVM, по крайней мере слово «Started» на это намекает.

В любом случае, позырить в лог можно из emergency.target (или с init=/bin/sh). Что-бы туда выпадать автоматом — засунуть OnFailure=emergency.target в default.target

(опустим вопрос, в каком из возможных каталогов мне искать default.target) После OnFailure=emergency.target ничего не изменилось. Собственно, Failure-то нет, ни один сервис не выдал Fail. Он просто висит и все. Что дальше?

Помимо огромного количества bolierplate кода

Ты --- глупенький? Запили свой дистрибутив с карточными играми и отсутствием boilerplate, которое, кстати, пишется именно так, а не так, как ты написал, пытаясь блеснуть знаниями английского языка (спасибо хоть, что не в такой степени как дебилушка littlechris).

Вынеси все эти общие функции в /etc/init.d/functions в дополнение к уже имеющимся, раз у тебя от них глаза вытекают и сурси их из скриптов. Не вижу зачем для решения этой проблемы нужен systemd, если это вообще считать проблемой.

emergency.target (или с init=/bin/sh)
init=/bin/sh

Реквестирую тег «история успеха»!

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

systemctl show -p FragmentPath default.target

cp $(systemctl show -p FragmentPath default.target) /etc/systemd/system/default.target; vim/etc/systemd/system/default.target

Собственно, Failure-то нет, ни один сервис не выдал Fail. Он просто висит и все. Что дальше?

systemctl show -p OnFailure default.target

Если сервис не запустился — он зафейлился. Если systemd запускает default.target (если другого не указано в cmdline), и если он не запустился — он должен запустить юнит OnFailure, если указан.

grep systemd.unit /proc/cmdline

systemctl show -p Requires -p Wants default.target

А юниты системд, это полноценное ПО? Или неполноценное? Вон из треда, сказали же.

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

Перезапускай сервис командой `service XXX restart` (или что там используется в твоем дистрибутиве). Если после этого все равно будет баг, то:
1. Добавь в /sbin/service (это обычный шелл-скрипт) строку:

cat /proc/1/loginuid > /proc/self/loginuid 2>&1

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

(положим, это redhat): xdm останавливается через init [^5]. sshd - через service sshd stop, какой-нибудь rsyncd - service xinetd stop; запущенное daemontools-ом - svc что-то-там; добавь к этому разные sudo для полной картины.

Если это redhat, то иксы (любые, prefdm) останавливаются через init не-5, все остальное через service. Daemontools-ов там, насколько я помню, нет. А что? Видимо, это был какой-то тонкий намек. Но он был настолько тонкий, что я не пойму, к чему это вообще относится. :)

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

Конечно не значит. Однако если «нечто» позволяло решать любую задачу в течение последних 20 лет, то это таки значит, что оно было лучшим.

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

Когда мне надо забить гвоздь, я не пытаюсь сделать это кулаком, я беру внешнюю сущность — молоток. От этого молоток не становится костылем, он становится инструментом. Все проблемы init-а были решены добавлением необходимых для этого инструментов. Кстати, systemd имеет точно такой же набор инструментов. Только его инструменты не справляются с задачей из-за убогости дизайна, поэтому с ними в комплекте идет и пачка костылей (например, те же бывшие шелл-скрипты, но теперь переписанные на Си).

PS: Похоже, мы понимаем под словом «костыль» разные вещи. Что ты называешь словом «костыль»?

Он просто висит и все

Хотя если там действительно что-то подвисло, то тогда имеет резон запихать еще и JobTimeoutSec

Ага. Проверено минуту назад, `service sshd restart` работает через ssh и не обрывает сессию. Не помню, чтобы с этим были какие-то проблемы. Разве что какой-то упоротый мейнтейнер написал init-скрипт, который делает restart методом `killall sshd`.

Это неверное поведение, только подтверждающее порочность initscripts в этой части. Restart, это по определению грубое действо, короткий аналог последовательности stop->start. А тут взяли и переделали restart в reload.

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

for service in /etc/init.d/*; do service $service status; done

приводила к отключению.

PS: Да, кстати, initscript еще рулят тем, что даже если мейнтейнер был встельку пьян и написал бред в initscript, то баг легко найти и исправить.

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

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

А в systemd один и тот же код используется для всех сервисов. И проект один. Я сам не в восторге от текущего положения дел со стабильностью и надежностью работы systemd, но очевидно, что при существующем темпе он в федоре 18-19 догонит и перегонит initscrits по надежности.

 cat /proc/1/loginuid > /proc/self/loginuid 2>&1 

Это же не будет работать. AUID immutable (ну по крайней мере во всех адекватных билдах)

Конечно не значит. Однако если «нечто» позволяло решать любую задачу в течение последних 20 лет, то это таки значит, что оно было лучшим.

Однако если это «нечто» выкинули через 20 лет, то это таки значит, что нашлось что-то получше (относительно того, там где выкинули)

Если сервис не запустился — он зафейлился. Если systemd запускает default.target (если другого не указано в cmdline), и если он не запустился — он должен запустить юнит OnFailure, если указан.

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

systemctl show -p OnFailure default.target

OnFailure=emergency.target

grep systemd.unit /proc/cmdline

ничего

systemctl show -p Requires -p Wants default.target

Requires=multi-user.target
Wants=gdm.service systemd-readahead-collect.service systemd-readahead-replay.service firstboot-graphical.service systemd-update-utmp-runlevel.service iscsid.service livesys.service livesys-late.service iscsi.service

Что дальше?

# systemctl enable sshd-keygen@rsa.service
# systemctl enable sshd-keygen@dsa.service
# systemctl enable sshd-keygen@ecdsa.service

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

Кстати, это еще не все, оригинальный shell-скрипт для них делал два chmod-а и restorecon — это еще сколько юнитов? Боюсь, шелл-скрипт будет не только проще и понятнее, но еще и короче. :)

Посмотри таки в лог

Wants=gdm.service

Печально, что на login рассовывают мягкие зависимости. Возможно там действительно затесался кривой юнит. Добавь в default.target еще JobTimeoutSec=40, например.

Но это не поможет, если таргет достижим. Так что я бы запихал gdm.service в Requires

для них делал два chmod-а

Которые не нужны, т.к. их делает кейген

и restorecon

Ок, согласен. Засунуть после первого ExecStart:

ExecStart=-/sbin/restorecon /etc/ssh/ssh_host_%i_key

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

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

Проблемы? Почти юниксвей :D Ты можешь:

1. поотрубать ненужные куски, не правя вендор скрипт

2. добавить хуки не правя вендор скрипт

Requires=pulseaudio.service

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

Ну и да. Ознакомиться с тем что должно было произойти можно с

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

Это к Axon AFAIR. Он так пульсом пользуется. У меня внешних звуковух нет. Но у меня есть псевдо-нищебродо-док с network транспортом для дома и работы. Динамическое переключение можно делать ок

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

Это же не будет работать. AUID immutable (ну по крайней мере во всех адекватных билдах)

А как же тогда pam_loginuid его меняет? ;) Попробуй в рутовом шелле сделать:

echo 12345 > /proc/self/loginuid

Однако если это «нечто» выкинули через 20 лет, то это таки значит, что нашлось что-то получше (относительно того, там где выкинули)

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

Пульс без сетевух сделает dummy вывод. Бессмысленно, но безопасно

А как же тогда pam_loginuid его меняет? ;)

Фишка в том, что он меняется только один раз, с -1 на тот, который ставится при логине. Системный инстанс не логинился не разу, и по этому работает с AUID==-1

Добавь в /sbin/service

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

это был какой-то тонкий намек

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

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

*было*

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

Предлагаю «средство компенсации недостаточно полно/правильно реализованной/работающей функциональности». Примеры: рука не разрабатывалась для забивания гвоздей, молоток - не костыль. man init говорит, что «Its primary role is to create processes», и оно с этой ролью справляется плохо (местами; getty, например, там вполне комфортно), приходится подставлять костыль rc. Сами init.d/скрипты запуска конкретных сервисов под категорию «костыли» попадают с трудом - они реализуют _непредусмотренную_ ни в запускаемой программе ни в остальных кусках системы функциональность, т.е. являются, скорее, «клеем» между сервисом, rc, системными политиками и пр. настройками. Но, в принципе, средство приклеивания костыля можно считать его частью — но тут грань размыта, вероятно можно говорить «клей костыльности ¼».

Это неверное поведение, только подтверждающее порочность initscripts в этой части. Restart, это по определению грубое действо, короткий аналог последовательности stop->start. А тут взяли и переделали restart в reload.

Не вижу связи. Reload — перечитывание конфига (в systemd его вообще нет), а restart перезапуск демона. Почему restart должен убивать живые сессии. Более того, почему stop должен убивать живые сессии?

А в альтлинуксе был чюдный сервис, который в ответ на status (по правде говоря, в ответ на любую команду) глушил компьютер.

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

for service in /etc/init.d/*; do service $service status; done

service --status-all

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

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

Еще один момент - многие вещи очень трудно корректно написать на уровне баш-скрипта.

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

А в systemd один и тот же код используется для всех сервисов.

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

но очевидно, что при существующем темпе он в федоре 18-19 догонит и перегонит initscrits по надежности.

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

Reload — перечитывание конфига (в systemd его вообще нет)

 > systemctl --help | grep reload
     --no-reload      When enabling/disabling unit files, don't reload daemon
  reload [NAME...]                Reload one or more units
  reload-or-restart [NAME...]     Reload one or more units is possible,
  reload-or-try-restart [NAME...] Reload one or more units is possible,
  daemon-reload                   Reload systemd manager configuration

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

Наверное незачем. По этому этого никто и не делает

Посмотри таки в лог

В логе в этот момент тишина.

Возможно там действительно затесался кривой юнит. Добавь в default.target еще JobTimeoutSec=40, например.

О, прогресс! После добавления OnFailure=emergency.target и JobTimeoutSec=40 в default.target мы вывалились в консоль. Никаких fail-ов все еще нет.

Что смотреть дальше?

 > systemctl --help | grep reload
     --no-reload      When enabling/disabling unit files, don't reload daemon
  reload [NAME...]                Reload one or more units
  reload-or-restart [NAME...]     Reload one or more units is possible,
  reload-or-try-restart [NAME...] Reload one or more units is possible,
  daemon-reload                   Reload systemd manager configuration

Точно, появился же уже параметр ExecReload, теперь в systemd тоже есть reload.