Systemd 29

И systemd и sysvinit «узнают» об этом одинаково

А об этом поподробнее. Как init-скрипты узнают о том, что процесс завершился, если он демонизировался? SysVinit (но не скрипты!) получит SIGCHILD, но он его не обрабатывает. init-скрипты не узнают, что sshd сдох.

Но зато если я остановлю ssh, то sysvinit узнает и больше ничего не сделает, если процесс не числился в respawn

в respawn

Ага, мне ещё sshd в inittab прописать надо. Просто супер. Если он respawn, то не смогу остановить, а если once, то не смогу потом ещё раз запустить.

А systemd по всем правилам его перезапустит, а чо, он же «внезапно» завершился...

А вот этого не надо:

laptop ~ # systemctl status sshd.service 
sshd.service - SSH Secure Shell Service
	  Loaded: loaded (/lib/systemd/system/sshd.service)
	  Active: active (running) since Mon, 20 Jun 2011 15:15:55 +0300; 12min ago
	Main PID: 5447 (sshd)
	  CGroup: name=systemd:/system/sshd.service
		  └ 5447 /usr/sbin/sshd -D
laptop ~ # killall sshd
laptop ~ # systemctl status sshd.service 
sshd.service - SSH Secure Shell Service
	  Loaded: loaded (/lib/systemd/system/sshd.service)
	  Active: failed since Mon, 20 Jun 2011 15:28:56 +0300; 1s ago
	 Process: 5447 ExecStart=/usr/sbin/sshd -D (code=exited, status=255)
	  CGroup: name=systemd:/system/sshd.service
laptop ~ #

>/usr/lib/tmpfiles.d/legacy.conf:d /run/lock/subsys 0755 root root -

Спасибо за строку, себе в Генту пропишу =)

Это всё есть в Perl ;)

Так это переписывать надо было бы.

Это заметно более простая и прямая задача, чем написание systemd и разной кухни для него. Выбор Perl'а был бы оптимален с точки зрения «фич для админа», но тогда пришлось бы выделить какой-то пакет «perl-rt», минимально-достаточный с точки зрения объёма и возможностей. Можно взять язык полегче, тот же Tcl.

>>> Это всё есть в Perl ;)

Так это переписывать надо было бы.

Это заметно более простая и прямая задача, чем написание systemd и разной кухни для него.

Я по религиозным причинам предпочту всё, что угодно, но не перл %)

Я по религиозным причинам предпочту всё, что угодно, но не перл %)

LOL. Программисты-ваххабиты ;)

>systemd прибил процесс. Он успешно справился с этой задачей. Но при этом дал _больше информации_, чем SysVinit: оказывается, процесс некорректно завершился. И если процесс _внезапно_ завершится (без команды stop), то systemd сразу об этом узнает, а SysVinit - не раньше команды status.

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

>> А если есть, то она ОБЯЗАНА тормозить загрузку всех сервисов, зависящих от local_fs.

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

Если она записана в fstab - от нее зависит все, что зависит от local_fs. О чем я и написал. Это и есть задача fstab-а.

Если я хочу, чтобы она монтировалась не вместе с local_fs, а тогда, когда появится, я ее впишу не статическим монтированием, а либо autofs, либо вообще noauto. И, да, к init-демону это отношения не имеет, и отлично работало до systemd. Зато systemd успел это пару раз сломать (он поначалу монтировал даже noauto).

Ога, напишем для каждого устройства по правилу udev.

И... это давно сделано! Ты не поверишь, это делается так:

ACTION==«add», SUBSYSTEM==«bluetooth», RUN+=«/usr/sbin/bluetoothd --udev»

Правда, это конфликтует с systemd, поэтому с приходом systemd это правило убрали.

И для usb-принтера udev почему-то cups не запускает

Вообще-то cups работает даже если в системе нет ни одного принтера, или если принтер сетевой и находится на другой машине. Запускать его из udev - это баг.

Зато можно, например, запускать его из xinetd, чтобы он запускался тогда, когда его пытаются использовать. И... барабанная дробь... это тоже уже сделано (/etc/xinetd.d/cups-lpd).

а в systemd это делается гораздо проще.

Точно. В systemd bluetooth вообще не стартует. Совсем. Проверено на F15. Очередной эпик фейл «событийно-ориентированная модели systemd».

>/lib/systemd/system/sshd.service

Какой ужас. А напрямую он его не может запустить? Зачем эта обёртка?

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

Я же писал выше. SysVinit показывает OK/FAIL на основе того, убилось или нет. systemd показывает failed на основании кода завершения демона. В обоих случаях демон убился и завершился с кодом 255. Тогда SysVinit покажет OK, а systemd failed. FAIL в SysVinit означает «не прибился», failed в systemd означает «прибился с кодом != 0». Так понятнее?

Какой ужас. А напрямую он его не может запустить? Зачем эта обёртка?

Это не обёртка. Это юнит, в котором написаны зависимости для sshd. Вот он:

[Unit]
Description=SSH Secure Shell Service
After=syslog.target

[Service]
ExecStart=/usr/sbin/sshd -D

[Install]
WantedBy=multi-user.target

Здесь всего лишь написано, что systemd напрямую запустит команду '/usr/sbin/sshd -D' сразу после того, как будет готова 'syslog.target'.

> Gentoo, УМВР. А bluetooth не пашет, скорее всего, потому же. почему и мой WiFi в Fedora - ядро не содержит нужных модулей.

Нет, написал в предыдущем сообщении, это из-за systemd. Запуск из udev-а отключили, а из systemd он не работает.

Тут как раз задача одна - запуска сервисов по многим условиям.

Ну так и я о том же. Запуск сервисов по многим условиям. Апач httpd запускает cgi - чем не запуск сервисов? Значит надо сделать его частью systemd. И я уверен, очень скоро можно будет запускать php-cgi прямо из systemd. А может быть можно уже сейчас.

Дальше. Что такое Х-ы? Это же бесконечный запуск разных сервисов. Вот я ткнул на иконку браузера и ЗАПУСТИЛСЯ firefox. А потом я ткнул на файл, и ЗАПУСТИЛСЯ видео-плеер. А значит все рабочее окружение тоже должно быть частью systemd. Бред? Нет, уже реальность, binfmt - реакция на попытку запуска - уже частично интегрирована в systemd, и никто не мешает захардкодить там плеер при запуске avi-файлов.

Осталось только интегрировать ядро в systemd.

>Так понятнее?

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

>Вообще-то cups работает даже если в системе нет ни одного принтера, или если принтер сетевой и находится на другой машине. Запускать его из udev - это баг.

Это фича. В systemd можно сделать оба варианта: чтобы cupsd всё время работал или чтобы cupsd запускался при подключении принтера.

Зато можно, например, запускать его из xinetd, чтобы он запускался тогда, когда его пытаются использовать. И... барабанная дробь... это тоже уже сделано (/etc/xinetd.d/cups-lpd).

Так тоже можно. Активация по сокету с помощью cups.socket с содержимым, аналогичным sshd.socket или avahi-daemon.socket.

Точно. В systemd bluetooth вообще не стартует. Совсем. Проверено на F15. Очередной эпик фейл «событийно-ориентированная модели systemd».

Это не systemd виноват, т.к. мой bluetooth у меня в Генте стартует. Я же говорю, скорее всего, там криво собранное ядро (без модулей для твоего блютуса). Мой вайфай тоже отключён в ядре федоры.

>Осталось только интегрировать ядро в systemd.

Наоборот, systemd в ядро.

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

Может, ты мне объяснишь, в чём проблема? В одной красной строке в выводе 'systemctl --no-pager'? Она помогла найти баг в sshd. То, что sshd всегда выходит с кодом 255 - ССЗБ. Или systemd должен городить костыли и кричать, что 255 - это нормальное завершение? Всегда код != 0 был аварийным выходом.

>Здесь всего лишь написано, что systemd напрямую запустит команду '/usr/sbin/sshd -D' сразу после того, как будет готова 'syslog.target'.

А что оно делает lib? Там вроде конфиги запрещают хранить.

>> Правда, раньше все работало, а теперь полезли проблемы, но мы не будем считать это проблемами, мы назовем это «прогрессом».

Какие проблемы? Что, sshd не останавливается? Или потом не запускается? Всё работает, как надо.

О, да, все работает. Проблемы лезут из всех щелей, но мы их не видим.
У suse вдруг возникли проблемы с initramfs, хотя раньше их не было.
Глюки при разборе fstab.
Shutdown не работает, хотя раньше работал.
При выключении портится файловая система / рассыпается рейд, хотя раньше этого не было.
Bluetooth не стартует, хотя раньше стартовал.
Сервисы, которые десять лет запускались нормально, вдруг начали выдавать ошибки запуска.
chkconfig --list больше не работает, и аналогов ему нет.
У systemd собственная система монтирований, и определить, что когда монтируется и монтируется ли вообще - невозможно.
При этом конфиги его разбросаны по всей файловой системе - что-то в /etc-е, что-то в /lib-е, что-то в /usr-е, и в каждом каталоге есть разные подкаталоге (systemd, tmpfiles.d, modules-load.d, sysctl.d, binfmt.d).
По сути конфиги стало почти невозможно читать. И идущие в комплекте пачки костылей и подпорок имеют такой же очевидный синтаксис:
ExecStart=/bin/systemd-tmpfiles --create --remove

Это не считая еще десятков багов, которые уже исправили, и багов, которые еще вылезут.

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

>Может, ты мне объяснишь, в чём проблема?

Проблема в том, что продукт не тестировали. Только и всего.

В одной красной строке в выводе 'systemctl --no-pager'? Она помогла найти баг в sshd. То, что sshd всегда выходит с кодом 255 - ССЗБ. Или systemd должен городить костыли и кричать, что 255 - это нормальное завершение? Всегда код != 0 был аварийным выходом.

Меня мало волнует источник ошибки. Поставил systemd, а она вылезла. Следовательно, systemd виноват, раз не учитывает багофичей и то что его автор не потрудился исправить эту проблему в том же ssh, перед тем как пихать во все дистры. В pptp, ктсати, тоже надо исправить. Как впрочем, и в mysql, а не городить эти идиотские ограничения на разделы.

>У suse вдруг возникли проблемы с initramfs, хотя раньше их не было.

systemd предполагает, что при запуске rootfs смонтирована в ro. В SUSE была кривая initramfs.

Глюки при разборе fstab.

Это кривой fstab был, а не глюки. Разбирает fstab он правильно.

Shutdown не работает, хотя раньше работал.

Не в тему. Если ты про ссылку на ЛОР, которую я кинул выше, хоть бы сходил по ней. Там тред про SysVinit. Так что «Shutdown не работает, хотя раньше работал» - в SysVinit, а не systemd.

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

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

Bluetooth не стартует, хотя раньше стартовал.

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

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

Примеры в студию. Не знаю ни одного такого сервиса.

chkconfig --list больше не работает, и аналогов ему нет.

https://fedoraproject.org/wiki/SysVinit_to_Systemd_Cheatsheet/ru

chkconfig frobozz --list

ls /etc/systemd/system/*.wants/frobozz.service

Оно?

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

cat /etc/fstab && find /lib/systemd /etc/systemd -name '*.mount'

При этом конфиги его разбросаны по всей файловой системе - что-то в /etc-е, что-то в /lib-е, что-то в /usr-е, и в каждом каталоге есть разные подкаталоге (systemd, tmpfiles.d, modules-load.d, sysctl.d, binfmt.d).

В /usr/lib/systemd только таргеты. Их нельзя менять.

В /lib/systemd сервисы и таргеты дефолтные. Их не надо менять. Если их надо поменять, идём в /etc/systemd. Там юниты юзерские. Там можно создавать свои и менять те, что в /lib/systemd.

По сути конфиги стало почти невозможно читать. И идущие в комплекте пачки костылей и подпорок имеют такой же очевидный синтаксис:

Маны тоже невозможно читать? Я, когда впервые в жизни увидел /etc/inittab, вообще нифига не распарсил. Какие-то буквы, двоеточия, цифры, хрень. А юниты смог прочитать раньше, чем man.

>его автор не потрудился исправить эту проблему в том же ssh

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

>перед тем как пихать во все дистры

В мою Генту он ничего не пихал. Я сам себе установил то, что мне понравилось. А если ты пользуешься говнодистрибутивами - ССЗБ. Вот в Fedora 16 будет по дефолту btrfs. А в menuconfig написано «Unstable disk format». Тогда точно все твои сервера накроются.

>А что оно делает lib? Там вроде конфиги запрещают хранить.

Юниты из /lib/systemd - это не конфиги. Их нельзя менять. Если их надо поменять, то надо скопировать в /etc/systemd и там менять.

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

А почему не должен? Его поделие не работает же. А уж как он там будет это делать - вопрос другой. Вешать багу, или самолично. Главное - рабочий дистрибутив.

всё, что угодно, но не перл

И даже лисп?

>> всё, что угодно, но не перл

И даже лисп?

Ооо, если бы только systemd был на Лиспе %)

Господа, есть ли какой-нибудь вменяемый мануал по использованию systemd в условиях генты? ну или хотя бы не генты, а вообще. Команды там всякие и вообще.

>В мою Генту он ничего не пихал.

А кто пихал в дебиан, сузе, федору? Он ещё почти года назад заявил, что его продукт полностью готов.

> Это фича. В systemd можно сделать оба варианта: чтобы cupsd всё время работал или чтобы cupsd запускался при подключении принтера.

Без systemd тоже можно сделать оба варианта. Вывод - systemd не нужен?

Так тоже можно. Активация по сокету с помощью cups.socket с содержимым, аналогичным sshd.socket или avahi-daemon.socket.

Опять таки...

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

Наиболее вероятный вариант - он будет разрастаться, тормозить и глючить. Весь мир будет героически пытаться исправить в нем ошибки. Юзеры будут мучаться. По всему инету будут развешаны howto fix systemd, как они сейчас развешаны для pulseaudio. У виндотроллей будет новый повод «у вас даже система нормально не грузится», и все, что линуксоиды смогут сказать в ответ - УМВР. А сами будут долго и мучительно бороться с глюками в каждом очередном бинарном костыле systemd. Леннарт в конце концов забросит разработку, как он забросил пульс, и найдет себе новую игрушку. А мейнтейнеры будут продолжать пихать его во все дистрибутивы, потому что убрать его - это признаться в собственной тупости.

Лучший вариант, маловероятный - все дружно протрезвеют и выкинут это убожество. А вместо него оставят маленький обратно-совместимый рабочий вариант (примерно как upstart v0.3), без лишних костылей и подпорок, который делает одну единственную задачу - быстро грузит систему - но делает ее хорошо.

>Юниты из /lib/systemd - это не конфиги. Их нельзя менять. Если их надо поменять, то надо скопировать в /etc/systemd и там менять.

А что это? Библиотеки? Не похоже.

>Лучший вариант, маловероятный - все дружно протрезвеют и выкинут это убожество. А вместо него оставят маленький обратно-совместимый рабочий вариант (примерно как upstart v0.3), без лишних костылей и подпорок, который делает одну единственную задачу - быстро грузит систему - но делает ее хорошо.

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

>Господа, есть ли какой-нибудь вменяемый мануал по использованию systemd в условиях генты? ну или хотя бы не генты, а вообще. Команды там всякие и вообще.

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

https://wiki.archlinux.org/index.php/Systemd

http://wiki.opennet.ru/Systemd_для_администраторов

http://0pointer.de/blog/projects/systemd.html

Другие ссылки в этом треде.

Мои посты здесь: http://www.linux.org.ru/forum/general/6403573?lastmod=1308562672109 (это об установке, оверлей systemd протух)

Остальное гуглится.

>Маловероятно. Не удивлюсь, что этого товарища оплачивает майкрософт.

Пруф или не было.

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

>По всему инету будут развешаны howto fix systemd, как они сейчас развешаны для pulseaudio.

Что-то ни разу не встречал про пульс. Раньше видел только много предложений его удалить. Сейчас он у меня работает, не жалуюсь. Глюков НЕТ. systemd уже почти допилен, он уже работает без глюков, всё будет нормально. Лучше бы беспокоились о том, что будет, когда btrfs будет по дефолту в федоре. Это страшнее.

А че? Она вполне для тестинга готова. Федора тоже)

> systemd предполагает, что при запуске rootfs смонтирована в ro. В SUSE была кривая initramfs.

Во-первых, это предположение неверно, потому что на livecd rootfs rw. Во-вторых, этой проблемы не было раньше, она возникла при переходе на systemd. Значит виноват - systemd.

> Это кривой fstab был, а не глюки. Разбирает fstab он правильно.

Да, только mount не считал его кривым. И спецификации он тоже не противоречил. И без systemd проблем не было. А вот с systemd возникли.

Интересная логика. По этой логике если я сделаю от рута rm -rf /* и система перестала грузиться, то это не у меня нет мозгов, а баг в rm, что удалил все файлы, и баг в ядре, что не помешало ему.

> Если ты про ссылку на ЛОР, которую я кинул выше, хоть бы сходил по ней.

`shutdown -h 20m` уже работает?

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

Леннарт обычно отвечает также. УМВР, NOTABUG.

> У меня стартует. Скажи лучше своим федорам, чтобы ядро нормально собрали.

Если запустить его вручную - оно работает. Может у тебя оно тоже стартует при запуске системы, а? ;)

> Примеры в студию. Не знаю ни одного такого сервиса.

sshd, pptp, кто там еще в этом треде упоминался? Хотя да, это же не баг в systemd, он все делает правильно. А кто решил, что это правильно? Ну, systemd и решил. См. «Интересная логика» выше.

> ls /etc/systemd/system/*.wants/frobozz.service Оно?

Нет. Cписок всех сервисов с информацией о том, какой из них запускается на каком runlevel-е. Во все времена это делала команда `chkconfig --list`. Пример:

$ chkconfig --list
ConsoleKit      0:выкл  1:выкл  2:выкл  3:вкл   4:вкл   5:вкл   6:выкл
NetworkManager  0:выкл  1:выкл  2:выкл  3:выкл  4:выкл  5:выкл  6:выкл
acpid           0:выкл  1:выкл  2:вкл   3:вкл   4:вкл   5:вкл   6:выкл
anacron         0:выкл  1:выкл  2:вкл   3:вкл   4:вкл   5:вкл   6:выкл
[...]
vsftpd          0:выкл  1:выкл  2:вкл   3:вкл   4:вкл   5:вкл   6:выкл
winbind         0:выкл  1:выкл  2:выкл  3:выкл  4:выкл  5:выкл  6:выкл
wpa_supplicant  0:выкл  1:выкл  2:выкл  3:выкл  4:выкл  5:выкл  6:выкл
xfs             0:выкл  1:выкл  2:вкл   3:вкл   4:вкл   5:вкл   6:выкл
xinetd          0:выкл  1:выкл  2:выкл  3:вкл   4:вкл   5:вкл   6:выкл

сервисы на основе xinetd:
        echo-dgram:     выкл
        echo-stream:    выкл
        rsync:          выкл
[...]

> cat /etc/fstab && find /lib/systemd /etc/systemd -name '*.mount'

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

> А юниты смог прочитать раньше, чем man.

Читать их легко. А теперь открой произвольный юнит в системе и скажи, когда он запустится и запустится ли вообще? Простой вопрос же. Для sysvinit он даже не приходил в голову, ответ был очевиден. А для systemd ответить на него невозможно, не просмотрев все скрипты, начиная от default-target-а. В чем же тогда польза от этих юнитов, если невозможно ни сказать, что они делают, ни даже узнать, сработают ли они?

> Что-то ни разу не встречал про пульс. Раньше видел только много предложений его удалить. Сейчас он у меня работает, не жалуюсь. Глюков НЕТ.

http://en.gentoo-wiki.com/wiki/PulseAudio
https://wiki.archlinux.org/index.php/PulseAudio
http://forums.fedoraforum.org/showthread.php?t=225660
http://ubuntuforums.org/showthread.php?t=789578
http://ubuntuforums.org/showthread.php?t=852822
(по форумам мандривы и opensuse первыми ссылками гуглистся howto kill pulseaudio)

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

Есть ли хоть один дистрибутив, в котором пульс «поставил и работает»?

Хотя да, если музыку через него слушать раз в день, то он «работает». А когда постоянно включен скайп, установлен tv-тюнер и играет mp3-плеер, то щелчки во время разговора и подхрипывания пульса даже при переключении рабочего стола дико достают. А когда во время просмотра DVD из-за короткой задержки привода он виснет и звук исчезает совсем - хочется с размаху встетить его автора с наковальней.

> (примерно как upstart v0.3), без лишних костылей и подпорок, который делает одну единственную задачу - быстро грузит систему - но делает ее хорошо.

Это upstart-то делает ее хорошо? Смешно.

Прописывать явно зависимости для сервисов — зло и идея on-demand вызова сервисов весьма хороша. Возможность скриптовать, конечно, хотелось бы оставить, но проще уж прикрутить какой-нибудь dsl для этого, типа как в sudo.

Ты неудачный криворученко какой-то.

> Прописывать явно зависимости для сервисов — зло

Обоснуй.

>Есть ли хоть один дистрибутив, в котором пульс «поставил и работает»?

В Gentoo поставил USE-флаг 'pulseaudio', emerge -avtuDN world и работает. Сразу. Ничего не настраивал.

> Прописывать явно зависимости для сервисов — зло

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

и идея on-demand вызова сервисов весьма хороша.

И она давно реализована (udev, xinetd). Каким местом она связана с init-демоном? Есть всего два варианта - сервис либо должен запускаться при загрузке либо не должен.

Если он должен запускаться при загрузке, то любой init-демон должен его запустит. Всегда, сразу, без условий.

Если он не должен запускаться при загрузке, то он вообще никак не связан с загрузкой и не имеет отношения к init-демону. Init запускает то, что нужно запустить при ЗАГРУЗКЕ системы. То, что нужно запустить в ответ на соединение, запускает xinetd. То, что запускается по времени, запускает крон. То, что запускается по клику мышкой на иконке - запускает файловый менеджер. То, что запускается по появлению устройст, запускает udev.

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

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

> Странно, во всех дистрибутивах во всех пакетных менеджерах прописаны такие зависимости. Что плохого в прописывании этих же зависимостей для сервисов?

Ну так и там глитчи случаются — про rpm (dll) hell не слышали? Просто в сфере управления файлами (пакетами) пока ничего лучше не придумали; systemd же предлагает проблему убрать; точнее, переложить ее на ядро, где реально таки проблемы и решаются (как избежать deadlock'ов и прочее)

Может... это... питон?

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

Программа. Насчет «всех возможных», правда, я не понял - есть единый граф завизмостей, он и проверяется.

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

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

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

> Ооо, если бы только systemd был на Лиспе %)

Да-а-а... вот тогда бы ты потроллил всласть? :)

> Если он должен запускаться при загрузке, то любой init-демон должен его запустит. Всегда, сразу, без условий.

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

> Может... это... питон?

Питон с инженерной точки зрения не подходит. Обычный шелл, в который встроены команды вроде grep и cut.

>> Ооо, если бы только systemd был на Лиспе %)

Да-а-а... вот тогда бы ты потроллил всласть? :)

Нет, тогда бы весь интернет дружно сказал «НАХ!».