Linux без systemd

[Rootlexx]

Как видите, никакие API systemd не ломались.

Я не говорил, что ломалось. Я говорил, поменялось. И оно таки поменялось.

Ну так в добавлении новых функций в API нет ровным счётом ничего плохого, если старые при этом никуда не деваются. Такие неломающие изменения API происходят постоянно в живых проектах, например, в ядре.
Добавление функций для управления cgroups в API systemd его не сломало и к тому же, как я объяснил, было вызвано решением разработчиков ядра.

Леннарт пишет, что некоторые компоненты systemd (в частности, logind) разрабатываются без заботы о возможности их отделения.

Тогда нефиг говорить о модульности. А он говорил. И в статье, которую я читал, об этом есть, и здесь, развенчивая мифы, Леннарт прямо говорит о модульности (см. миф №6 и в некоторой степени миф №1).
Если же компоненты разрабатываются без учёта возможного их отделения, тогда от модульности там - одно название.

Ну давайте пройдём по вашей ссылке и прочитаем (выделение моё):

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

В оригинале:

In fact, many of these binaries[1] are separated out so nicely, that they are very useful outside of systemd, too.

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

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

Да не решает он ничего.
Я уже говорил, что за всё время видел только один сервис, который падал на ровном месте и поэтому помогал тупой перезапуск.
А Вы много знаете таких сервисов?
Если же сервис упал по объективным причинам, то без вмешательства не запустится, тогда простой всё равно обеспечен.

Сервис мог упасть:
* по OOM,
* из-за определённых входных данных,
* из-за отсутствующей обработки маловероятной ошибки,
* по любой другой непостоянной причине.
Во всех таких случаях высока вероятность того, что сервис, будучи перезапущенным, будет исправно работать более-менее продолжительное время.
В результате, как я вам уже объяснял в другой теме, автоматический перезапуск в худших случаях такой же, а во многих - лучше, чем его отсутствие.

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

Если администратор профнепригоден, это не вина systemd.

[Hephaestus]

Ну так в добавлении новых функций в API нет ровным счётом ничего плохого, если старые при этом никуда не деваются. Такие неломающие изменения API происходят постоянно в живых проектах, например, в ядре.
Добавление функций для управления cgroups в API systemd его не сломало и к тому же, как я объяснил, было вызвано решением разработчиков ядра.

Почему тогда возникла проблема у Canonical?

Почему Леннарт пишет вот это?

And of course, just a few months after Canonical did this, things are broken again, and this was to be expected: logind now uses the new cgroups userspace APIs (as mentioned above), and hence it will not run without systemd around.

"Конечно, всё опять сломалось, как мы и ожидали." Мало того, что сломалось, так ещё и "опять", да ещё и "мы ожидали".
Для "ничего не ломающих изменений" это как-то уж совсем странно.

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

Вы привели цитату из мифа №1. Посмотрите внимательно на миф №6. Я ведь указывал, прежде всего, на него, но почему-то Вы не обратили внимания.

Сервис мог упасть:
* по OOM,
* из-за определённых входных данных,
* из-за отсутствующей обработки маловероятной ошибки,
* по любой другой непостоянной причине.
Во всех таких случаях высока вероятность того, что сервис, будучи перезапущенным, будет исправно работать более-менее продолжительное время.

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

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

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

Если администратор профнепригоден, это не вина systemd.

Да, я уже заметил, что ни Леннарт, ни systemd никогда ни в чём не виноваты. Что бы ни случилось, виноват всегда кто-то другой. И даже баги в самом systemd объявляются фичами.

[yars]

OOM -- это Out Of Memory, killer - убийца. Встревает, если системе вдруг начинает не хватать памяти, убивая наиболее прожорливого.

[Rootlexx]

Так выглядит скрипт в моей нынешней системе.

1. При неудачном старте не возвращается соответствующий код выхода. Да и вообще на ошибки проверок нет.
2. Зачем убивать процесс SIGKILL-ом? Не слишком ли жёстко? Потому у вас и остаётся lock-файл, что вы не даёте rtorrent шанс за собой прибрать.
3. Не проверяется, что под прочитанным из lock-файла PID-ом запущен действительно rtorrent. Если последний упал, то его PID мог занять другой процесс, который будет убит при остановке сервиса.
Я набросал такой сервис systemd:

Код: Выделить всё

[Unit]
After=network.target

[Service]
#EnvironmentFile=/home/alex/.rtorrentdaemonrc
Environment=TERM=linux
ExecStart=/usr/bin/dtach -n /tmp/rt0 -r winch -z /usr/bin/rtorrent
ExecStartPost=/bin/chmod 660 /tmp/rt0
Type=forking
User=user

[Install]
WantedBy=multi-user.target

Проверил, присоединившись с помощью $ dtach -a /tmp/rt0.

1. Где LSB-заголовки?
Без понятия. Делал на основе одного из штатных скриптов слаквари, нету их там. И, насколько я понимаю, не нужны.

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

2. Не указано, что скрипт должен стартовать после поднятия сети. (Впрочем, если rtorrent правильно обрабатывает её отсутствие, то это необязательно.)
Регулируется в другом месте.

Расскажите в двух словах.

[Rootlexx]

Почему тогда возникла проблема у Canonical?

И зачем я вам объясняю, если вы всё равно не читаете?..
Последняя попытка:
1. systemd и logind сами управляли своими cgroups. Благодаря этому Canonical без особых усилий использовали logind отдельно от systemd.
2. Разработчики ядра решили, что непосредственно управлять cgroups должен лишь один процесс. Поэтому logind более не мог сам управлять своими cgroups и стал использовать для этого новое API, предоставленное systemd.
3. Теперь Canonical было недостаточно просто выдрать logind из проекта systemd, но нужно было реализовать альтернативную реализацию API для управления cgroups, которую мог бы использовать logind. То есть проблемы у Canonical возникли не из-за добавления новых функций в API systemd, а потому что logind стал требовать наличия этих функций для своей работы по причинам, изложенным выше.

Почему Леннарт пишет вот это?

And of course, just a few months after Canonical did this, things are broken again, and this was to be expected: logind now uses the new cgroups userspace APIs (as mentioned above), and hence it will not run without systemd around.

"Конечно, всё опять сломалось, как мы и ожидали." Мало того, что сломалось, так ещё и "опять", да ещё и "мы ожидали".
Для "ничего не ломающих изменений" это как-то уж совсем странно.

А теперь давайте прочитаем предложение ровно перед процитированным вами куском:

logind of course is one of the components of systemd where we explicitly documented that it is not a component you can rip out of systemd.

Ровно то же самое я уже писал вам в этой теме пару сообщений назад:

Леннарт пишет, что некоторые компоненты systemd (в частности, logind) разрабатываются без заботы о возможности их отделения.

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

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

Вы привели цитату из мифа №1. Посмотрите внимательно на миф №6. Я ведь указывал, прежде всего, на него, но почему-то Вы не обратили внимания.

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

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

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

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

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

Да, я уже заметил, что ни Леннарт, ни systemd никогда ни в чём не виноваты. Что бы ни случилось, виноват всегда кто-то другой. И даже баги в самом systemd объявляются фичами.

Но мы-то знаем, что на самом деле во всём виноват systemd и Поттеринг лично. Если администратор не настроил оповещение в случае падения важного сервиса и не следит за сервером, надеясь на автоперезапуск, то он на самом деле ни в чём не виноват, это systemd - исчадие ада - коварно дал ему такую возможность. Слава богу, что он не использовал respawn - а то бы мы вообще без init-системы остались!
А знаете, что я тут подумал?.. А ведь если сервис автоматически запускается при загрузке системы, администратор тоже может понадеяться на автозапуск и не заметить, что сервис-то лежит! Узнаю подлое коварство! И сюда дотянулся systemd проклятый! Долой init-скрипты! Только запуск вручную, только хардкор! Аминь.

[Bizdelnick]

Rootlexx
Всё это, конечно, замечательно, но почему рулить cgroups — дело PID1?

[Hephaestus]

1. При неудачном старте не возвращается соответствующий код выхода. Да и вообще на ошибки проверок нет.

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

2. Зачем убивать процесс SIGKILL-ом? Не слишком ли жёстко? Потому у вас и остаётся lock-файл, что вы не даёте rtorrent шанс за собой прибрать.

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

3. Не проверяется, что под прочитанным из lock-файла PID-ом запущен действительно rtorrent. Если последний упал, то его PID мог занять другой процесс, который будет убит при остановке сервиса.

Опять-таки добавить не проблема. И опять-таки довольно маловероятная ситуация - не так много процессов на домашней машине, чтобы PID-ов не хватило.

Я набросал такой сервис systemd

Вы описали замечания в пяти пунктах выше и потом ещё три, и возможно, найдётся ещё, если подумать.
Вероятно, systemd обеспечивает выполнение всех этих пунктов, даже тех, которые Вы не называли, а возможно ещё и других, которые нам с Вами даже в голову не пришли. Я правильно понимаю? Если так, то замечательно.
Беда, однако в том, что в Вашем конфиге этого вообще никак не видно, и непонятно, что из этих пунктов обеспечено, а что нет. Что работает нормально, а что не совсем. И куды бечь, если работает ненормально, тоже не очень понятно.
Скрипты я пишу сам и рулю ими сам. И как они будут работать, зависит от меня. А вот как systemd обработает мои конфиги (правильно или нет) - это от меня не зависит вообще. Более того, я даже приблизительно не представляю, где находится код, который обрабатывает конкретную строку конкретного конфига. Поэтому если там где-то что-то пошло не так, докопаться до причины будет на порядок сложнее. Не говоря уже о том, что исправления, скорее всего, придётся вооружиться компилятором.

Расскажите в двух словах.

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

[Hephaestus]

И зачем я вам объясняю, если вы всё равно не читаете?..

Отчего же? Я как раз читаю.

То есть проблемы у Canonical возникли не из-за добавления новых функций в API systemd, а потому что logind стал требовать наличия этих функций для своей работы по причинам, изложенным выше.

Я не склонен думать, что в Canonical все как на подбор клинические идиоты, что они не разобрались вовремя в изложенных Вами деталях и понадеялись на переносимость.
И если они всё-таки не идиоты, то остаётся только один вариант: Леннарт изначально заявлял некие возможности, которых в дальнейшем не оказалось.
Изменение API - это серьёзная вещь, чреватая несовместимостью.
Насколько я понимаю, в таких случаях меняется номер версии продукта.
А у systemd с номерами версий вообще как-то не очень.
И в целом, Леннарт слишком легкомысленно относится к столь масштабному проекту.
Призывает дистростроителей внедрять его продукт, а сам даже не заботится об исправлении багов.
Несерьёзно как-то.

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

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

Если одного падучего сервиса достаточно, то и одного частного случая вреда тоже достаточно.

Но мы-то знаем, что на самом деле во всём виноват systemd и Поттеринг лично.

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

[Rootlexx]

Rootlexx
Всё это, конечно, замечательно, но почему рулить cgroups — дело PID1?

В принципе, это не обязательно. Скажем, в Ubuntu ранее это был отдельный процесс cgmanager. Но там init (upstart) не использовал cgroups.
systemd использует cgroups для отслеживания процессов сервисов, то есть для того, чем занимается PID 1. Код для управления cgroups несложен, так что вынесение его в отдельный процесс едва ли что-то сильно упростило бы, ибо cgroups необходимы systemd для правильного функционирования, и поэтому крах такого процесса всё равно был бы аварией, а с этим отдельным процессом пришлось бы создавать отдельный канал коммуникации.
Из обсуждения по одной из приведённых ссылок:

We do outside of PID 1 what makes sense to do outside of PID 1, thus the 80+ executable binaries in our tree. (I mean, in case this isn't clear: having 80+ executable binaries means you split up things into 80+ different processes). And no, cgroups and kdbus are not features that make sense to be split out. kdbus is how clients communicate with PID 1, so we need to set it up in PID1. That's a logic that is quite forcing, no? And then, cgroup support is used to spawn services, so how could you put that into another process if to start that process you need cgroups?

Я не склонен думать, что в Canonical все как на подбор клинические идиоты, что они не разобрались вовремя в изложенных Вами деталях и понадеялись на переносимость.
И если они всё-таки не идиоты, то остаётся только один вариант: Леннарт изначально заявлял некие возможности, которых в дальнейшем не оказалось.

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

Изменение API - это серьёзная вещь, чреватая несовместимостью.

Только если изменяется уже существующий, а не добавляется новый.

Если одного падучего сервиса достаточно, то и одного частного случая вреда тоже достаточно.

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

[Bizdelnick]

Код для управления cgroups несложен, так что вынесение его в отдельный процесс едва ли что-то сильно упростило бы

Даже если не упростило бы, то добавило бы ту самую модульность, которая в systemd якобы есть. Та архитектура, которая существует, обеспечивает vendor lock-in, это единственный её смысл.

kdbus is how clients communicate with PID 1

Я чего-то, наверное, не понимаю, но разве смысл dbus не в мультикасте? PID 1 по определению всегда один, почему для общения с ним не использовать что-то более простое (пайпы, сигналы)? Почему все так и делают, а systemd не может?

[Hephaestus]

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

Будущее никто не может видеть. И это не мешало людям разрабатывать софт.
И только у Леннарта почему-то что ни багрепорт, то скандал. Может что-то в консерватории подправить?(с)

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

Подтверждения моим словам я приводил из письма самого Леннарта.
Леннарт говорит: "Logind нельзя отделить от systemd" и "Logind теперь использует новый API"
Это означает ровно две вещи:
1.API поменяли (ничего другого я и не утверждал). Вы же с какой-то радости начали искать подтверждение "сломанного API", хотя про "сломанный" я не говорил вообще.
2.Logind раньше удавалось отделить, теперь нельзя. То есть, никакой модульности там и в помине нет.
Слова Леннарта о том, что компоненты разрабатываются без заботы об их возможном отделении - лучшее тому подтверждение.
Вы же хотите ещё каких-то подтверждений. Интересно, каких? Слов Леннарта Вам мало. А кто знает systemd лучше, чем он?

Только если изменяется уже существующий, а не добавляется новый.

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

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

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

[Rootlexx]

Код для управления cgroups несложен, так что вынесение его в отдельный процесс едва ли что-то сильно упростило бы

Даже если не упростило бы, то добавило бы ту самую модульность, которая в systemd якобы есть. Та архитектура, которая существует, обеспечивает vendor lock-in, это единственный её смысл.

Vendor lock-in лишь для тех, кто хочет использовать systemd как PID 1, но при этом хочет иметь другой менеджер cgroups, а не тот, что предоставляется systemd. Безусловно, это очень многочисленная группа, и встраивание менеджера cgroups в systemd имело цель захватить эти 5, а может даже 10 человек, а вовсе не упрощения кода и внутренней архитектуры. Правда, менеджер cgroups был встроен в systemd с самого начала, задолго до упомянутых изменений в ядре, когда каждый мог беспрепятственно управлять cgroups, и ни о каком lock-in не могло быть и речи, но, видимо, разработчики systemd предвидели будущее.

kdbus is how clients communicate with PID 1

Я чего-то, наверное, не понимаю, но разве смысл dbus не в мультикасте? PID 1 по определению всегда один, почему для общения с ним не использовать что-то более простое (пайпы, сигналы)? Почему все так и делают, а systemd не может?

Смысл dbus в более высокоуровневом IPC, нежели примитивы IPC. Зачем изобретать велосипед в виде собственного протокола, реализуя сериализацию данных, политики и т. д. вместо использования существующего решения, внутри, естественно, использующего те самые примитивы?

[alv]

Слов Леннарта Вам мало. А кто знает systemd лучше чем он?

Вы будете смеяться, но бытует версия, что systemd до пригодного к употребелнию вида допилили майнтайнеры Archlinux'а. И я её слышал вовсе не от фанатов названного дистрибутива.
Так что это вопрос спорный, кто лучше знал богословие - эмир, Ходжа или ишак...

[Bizdelnick]

Vendor lock-in лишь для тех, кто хочет использовать systemd как PID 1, но при этом хочет иметь другой менеджер cgroups, а не тот, что предоставляется systemd.

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

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

Да что ж они там передают-то такое друг другу по этому dbus?

[Rootlexx]

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

Естественно, ведь вы говорили об изменении API в негативном русле, что корректно только при изменении существующего (= ломания) API, а уж никак не при добавлении нового. Я исходил из того, что вы понимаете, о чём ведёте речь, но был неправ, признаю.

2.Logind раньше удавалось отделить, теперь нельзя.

Что, правда? А как тогда Canonical это сделали?

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

Некоторые компоненты. Понимаете? Не все, не большинство, а некоторые.

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

Да что ж вы не поймёте никак, али прикидываетесь? Изменение API здесь вообще не важно, API мог вообще не меняться и существовать с самого начала; главное в том, что logind начал использовать этот API, а значит, стал требовать его наличие для своей работы. И вызваны эти изменения были решением разработчиков ядра. Понимаете? Не systemd, а ядра.

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

Для вредности функции необходимо и достаточно, чтобы существовал случай, когда она вредна. При этом не нужно, чтобы она была вредна во всех случаях.

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

Vendor lock-in лишь для тех, кто хочет использовать systemd как PID 1, но при этом хочет иметь другой менеджер cgroups, а не тот, что предоставляется systemd.

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

Какой же здесь тогда lock-in? logind зависит от интерфейса, для которого можно создать сколько угодно альтернативных реализаций. Что, собственно, Canonical и сделали.

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

Да что ж они там передают-то такое друг другу по этому dbus?

Команды действий с сервисами, запросы и данные о состоянии и т. п..

[Bizdelnick]

Команды действий с сервисами, запросы и данные о состоянии и т. п..

Это для systemctl, что ли? Всё равно не понимаю, зачем dbus, а не сокет с не велосипедным, а любым стандартным протоколом (хоть JSON-RPC) поверх него.

[Rootlexx]

1. При неудачном старте не возвращается соответствующий код выхода. Да и вообще на ошибки проверок нет.

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

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

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

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

3. Не проверяется, что под прочитанным из lock-файла PID-ом запущен действительно rtorrent. Если последний упал, то его PID мог занять другой процесс, который будет убит при остановке сервиса.

Опять-таки добавить не проблема. И опять-таки довольно маловероятная ситуация - не так много процессов на домашней машине, чтобы PID-ов не хватило.

В том-то и дело, что написать init-скрипт более-менее легко, но вот написать его правильно, учитывая всевозможные граничные случаи, уже совсем не просто, а результат уж точно не будет элегантным и коротким. Так что для домашнего использования наспех слепленный скрипт, может, и подойдёт, но разработчики дистрибутивов, сопровождающие пакетов, администраторы не могут себе позволить убивать несвязанные с их сервисом процессы направо и налево и другие подобные вещи, и потому для них systemd, который позволяет писать коротко и корректно, полезен. Потому и не осталось почти крупных, серьёзных дистрибутивов, которые не перешли бы на него.
На systemd, кстати, свет клином не сошёлся: upstart тоже решает многие из упомянутых проблем, просто он требует подписывания CLA и ощутимо отстал в техническом плане, потому и проиграл. Но появился, как и systemd, не просто так без причины.

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

Да, в этом и суть.

Беда, однако в том, что в Вашем конфиге этого вообще никак не видно, и непонятно, что из этих пунктов обеспечено, а что нет.

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

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

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

[Rootlexx]

Всё равно не понимаю, зачем dbus, а не сокет с не велосипедным, а любым стандартным протоколом (хоть JSON-RPC) поверх него.

Так и есть: сокет с протоколом dbus поверх него. Чем плох выбор dbus?

[Bizdelnick]

Чем плох выбор dbus?

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

[Rootlexx]

Чем плох выбор dbus?

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

Если я ничего не пропустил, kdbus ещё даже не приняли в ядро, где же здесь "нужен"? На данный момент используется лишь библиотека libdbus для протокола и сокет как транспорт.

[Bizdelnick]

Тогда как надо понимать это высказывание?

cgroups and kdbus are not features that make sense to be split out. kdbus is how clients communicate with PID 1, so we need to set it up in PID1.

А в ядро вроде уже приняли, если я правильно путаю.

[Rootlexx]

Тогда как надо понимать это высказывание?

cgroups and kdbus are not features that make sense to be split out. kdbus is how clients communicate with PID 1, so we need to set it up in PID1.

Вероятно, если в ядре включён kdbus, то будет использоваться он (что на мой взгляд логично: какой смысл использовать свой механизм IPC вместо предоставляемого ядром?), а значит, PID 1 должен выполнить его инициализацию, чтобы запускаемые в дальнейшем процессы могли взаимодействовать с PID 1. Насколько знаю, на данный момент systemd kdbus не требует и вряд ли скоро будет.

[Hephaestus]

Естественно, ведь вы говорили об изменении API в негативном русле

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

Что, правда? А как тогда Canonical это сделали?

А то Вы не знаете!
Цитирую Вас же:

Никто не мешает создать альтернативную реализацию менеджера cgroups, предоставляющую этот API, что и было сделано Canonical в виде systemd-shim.

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

Некоторые компоненты. Понимаете? Не все, не большинство, а некоторые.

Во-первых, не надо таких текстовых выделений. Это равносильно крику. Извольте держать себя в руках.
Во-вторых, "некоторых компонентов" уже достаточно, чтобы никакая модульность не состоялась.
В-третьих, не совсем сходится вот с этим.

Миф №6: Systemd не модульный.
- Это не так: в сборочном скрипте configure есть ряд ключей, позволяющих указать какие именно части systemd требуется собрать. Таким образом выбор предоставляемых возможностей осуществляется на этапе сборки.

В оригинале текста есть ссылка на документ, который

And we document how you can select in even more detail what you need, going beyond our configure switches.

Об обязательных компонентах там написано, что:

The core components are always built (which includes systemd itself, as well as udevd and journald).

И далее в этом документе нигде не сказано, к примеру, что logind неотделяемый (в числе обязательных его нет).
Означает ли это, что systemd может быть собран без logind? По словам того же Леннарта, не может.
То есть формально оно вроде модульное, а потом начинается: то нельзя, сё нельзя...
Ну и толку от такой модульности?

Да что ж вы не поймёте никак, али прикидываетесь? Изменение API здесь вообще не важно, API мог вообще не меняться и существовать с самого начала; главное в том, что logind начал использовать этот API, а значит, стал требовать его наличие для своей работы. И вызваны эти изменения были решением разработчиков ядра. Понимаете? Не systemd, а ядра.

Хорошо. С какого бодуна Canonical решили портировать logind?
Если он разрабатывается без учёта отделения, с чего они вообще взялись его отделять?
Если бы Леннарт с самого начала чётко и ясно обозначил, что вот это и вот это неотделимо, остальное - пожалуйста, Canonical, наверно, не стали бы этого делать, так?

[Bizdelnick]

какой смысл использовать свой механизм IPC вместо предоставляемого ядром?

Вот я чуть выше тебя об этом же спрашивал: на фига им в принципе этот dbus упёрся?

[Hephaestus]

Вы игнорируете тот факт, что скрипты исполняются тоже не сами по себе, а сложным интерпретатором,

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

[Bizdelnick]

Посмотрел из любопытства описание d-bus API systemd. Зачем там всё это? Из методов менеджера реально полезны только StartUnit(), StopUnit(), ReloadUnit(), RestartUnit(), KillUnit(), Reboot(), PowerOff() и Halt(). Reload() ещё, но он заменяется SIGHUP. Методы юнитов дублируют вышеперечисленные и поэтому нафиг не нужны, из свойств юнитов есть прок только от LoadState и ActiveState (которые можно спокойно заменить единственным State). Всё, что описано ниже, или не имеет смысла, или дублирует информацию из файлов юнитов.
Объясните мне, неужели существует клиент, который использует хотя бы 10% этого API? Неужели есть вероятность, что он кому-то когда-то понадобится, и его напишут? На фига это всё писалось, чтобы зарплату как-то отбивать?

[Rootlexx]

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

В активных проектах, где регулярно появляется новая функциональность, естественно, появляются и новые функции в API, позволяющие эту функциональность использовать. За примерами далеко ходить не надо: ядро Linux. Кстати, не подскажете, где почитать его план развития? (Собор и Базар вы, видимо, не прочли.)

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

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

В-третьих, не совсем сходится вот с этим.

Миф №6: Systemd не модульный.
- Это не так: в сборочном скрипте configure есть ряд ключей, позволяющих указать какие именно части systemd требуется собрать. Таким образом выбор предоставляемых возможностей осуществляется на этапе сборки.

В оригинале текста есть ссылка на документ, который

And we document how you can select in even more detail what you need, going beyond our configure switches.

Об обязательных компонентах там написано, что:

The core components are always built (which includes systemd itself, as well as udevd and journald).

И далее в этом документе нигде не сказано, к примеру, что logind неотделяемый (в числе обязательных его нет).
Означает ли это, что systemd может быть собран без logind? По словам того же Леннарта, не может.
То есть формально оно вроде модульное, а потом начинается: то нельзя, сё нельзя...
Ну и толку от такой модульности?

У вас, похоже, каша в голове. Какая связь между возможностью компиляции systemd без logind и возможностью использования последнего отдельно от первого?
Можно ли собрать systemd без logind? - да, можно.
Поддерживается ли использование logind отдельно от systemd? - нет, не поддерживается.
То есть поддерживается использование systemd без logind, но не наоборот.

Хорошо. С какого бодуна Canonical решили портировать logind?
Если он разрабатывается без учёта отделения, с чего они вообще взялись его отделять?
Если бы Леннарт с самого начала чётко и ясно обозначил, что вот это и вот это неотделимо, остальное - пожалуйста, Canonical, наверно, не стали бы этого делать, так?

logind пришёл на смену consolekit, который был заброшен и перестал развиваться. Как следствие этого upstream стал потихоньку переходить на logind и отказываться от consolekit. В результате перед Canonical встал выбор: самим поддерживать consolekit и его интеграцию с используемым ПО или же выдрать logind из состава systemd. Был выбран второй вариант. Вероятно, Canonical посчитали, что это проще, чем тянуть на себе мёртвое ПО в то время как upstream уходит от него всё дальше.

[neol]

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

В этом месте хотелось бы передать пламенный привет ShellShock (=

Всё равно не понимаю, зачем dbus, а не сокет с не велосипедным, а любым стандартным протоколом (хоть JSON-RPC) поверх него.

http://dbus.freedesktop.org/doc/dbus-faq.html#xmlrpcsoap
Для JSON-RPC абсолютно аналогично. Он просто тупо медленнее.
И вообще, чем плох dbus, кроме того, что используется в systemd? Ну пришлось бы тащить не библиотечку для dbus, а библиотечку для JSON, XML или еще какой фигни. Это в корне что-то меняет?

из свойств юнитов есть прок только от LoadState и ActiveState (которые можно спокойно заменить единственным State)

LoadState и ActiveState - это разные состояния. Объединять их не нужно.

Объясните мне, неужели существует клиент, который использует хотя бы 10% этого API?

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

[Rootlexx]

Вот я чуть выше тебя об этом же спрашивал: на фига им в принципе этот dbus упёрся?

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

Методы юнитов дублируют вышеперечисленные и поэтому нафиг не нужны

По твоей же ссылке объясняется:

Note that many of the calls exist twice: once on the Manager object, and once on the respective unit objects. This is to optimize access times so that methods that belong to unit objects do not have to be called with a resolved unit path, but can be called with only the unit id, too.

Объясните мне, неужели существует клиент, который использует хотя бы 10% этого API?

Очевидно, systemctl.

[Hephaestus]

В активных проектах, где регулярно появляется новая функциональность, естественно, появляются и новые функции в API, позволяющие эту функциональность использовать. За примерами далеко ходить не надо: ядро Linux.

Изменение API - это новая версия ядра.
У ядра Linux есть строгая нумерация версий, которая позволяет сориентироваться, насколько серьёзны изменения.
Леннарт, похоже, вообще не заморачивается по таким пустякам.

Кстати, не подскажете, где почитать его план развития?

Спросите у Линуса. Если кто и знает, так это он.

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

Функция может и не отделяться. Хотя функция может быть размещена в модуле, тогда от проекта она вполне себе отделима. А вот в systemd это не просто функции, а самостоятельные программы, по крайней мере, так они заявлялись вначале. И теперь, когда оно вдруг становится неотделимым - это как минимум странно.

Какая связь между возможностью компиляции systemd без logind и возможностью использования последнего отдельно от первого?
Можно ли собрать systemd без logind? - да, можно.

Неужели? А вот Леннарт говорит, что нельзя. Кому верить?

Был выбран второй вариант. Вероятно, Canonical посчитали, что это проще, чем тянуть на себе мёртвое ПО в то время как upstream уходит от него всё дальше.

А ещё более вероятно, что на тот момент logind действительно был отделимым.
И они понадеялись на ту самую модульность, о которой заявлял Леннарт.
А потом logind стал неотделимым. И вот тут-то (если по-хорошему) Леннарту надо было немножко напрячься, чтобы имеющуюся модульность сохранить. Он этого оне сделал. С одной стороны, хозяин - барин.
Но с другой стороны, это несерьёзно, призывать к участию в проекте все дистры, а потом на ходу менять правила игры. А всё потому, что ответственности он нести не желает совсем.