Переход Ubuntu на Systemd

[jashaw5]

Посетители - линуксоиды некомпьютерных специальностей, применяющих Линукс в своей работе ушли на: http://linuxforum.ru/index.php. Увы.

очень не хочется вас обидеть.

Валяйте, посмеемся вместе. А на обиженных воду возят.

[drBatty]

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

[eddy]

Посетители - линуксоиды некомпьютерных специальностей, применяющих Линукс в своей работе ушли на: http://linuxforum.ru/index.php.

sed -e 's/линуксоиды/вендузятники/g' -e 's/Линукс/мастдайка/'

[Hephaestus]

Ну и демагогия... Я тоже так могу:

1. Для того, чтобы писать на C, нужно изучить КР.
2. Для того, чтобы пользоваться готовыми программами, нужно изучить документацию к этим программам.

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

При этом объём изучаемой документации в пером и втором случае сопоставим.

Второе даёт рыбу.
Первое учит рыбачить.

Долой готовые программы! Всем по компилятору за мой счёт!

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

Суть в том, что кроме простой задачи непосредственного запуска нужной программы приходится решать ещё кучу сопутствующих задач, для решения которых в sysvinit традиционно используется shell и куча костылей типа PID-файлов, и в которых и заключена основная сложность и запутанность. Вот как раз эти сопутствующие задачи systemd реализует на более подходящем для этого языке более подходящим способом. (Заодно перенося существующую в ядре функциональность из категории нигде толком не использующейся экзотики в категорию стандартных и доступных решений.)
Всё же есть разница между необходимостью скриптовать одну простую задачу в редких случаях и необходимостью скриптовать всё.

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

[Rootlexx]

Так процесс-то делает double fork и становится дочерним init. Поэтому поддержка этого должна быть в init, иначе никак.

нет. Процесс делается дочерним сам себе, а не init, и может отслеживать сам себя, если у него есть такая необходимость.

Вы неправы. Почитайте, как происходит демонизация. Вкратце:

• Первый раз процесс делает fork для создания фонового дочернего процесса.
• Дочерний процесс выполняет setsid для отсоединения от управляющего терминала. Однако это приводит к тому, что данный процесс становится лидером новой сессии и согласно POSIX.1-2008 (11.2.3) может получить новый управляющий терминал путём открытия файла устройства (например, /dev/console).
• Дочерний процесс делает ещё один fork, чтобы новый порождённый процесс не был лидером сессии и не мог открыть управляющий терминал. Этот новый процесс и становится демоном, а родительский процесс и его родительский процесс завершаются (первый - сразу, второй - по готовности демона), что приводит к усыновлению процесса демона init'ом. После этого получить код выхода процесса демона может только он.

Мало того, сам bash тоже может форкнуться, и отслеживать какой-то процесс.

вот вам тривиальный пример:

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

#!/bin/bash

sleep 1m &
ASYNC_PID=$!
top -n1 -p$ASYNC_PID

Здесь не происходит double fork, а top отслеживает лишь наличие процесса и не может получить его код выхода.

[drBatty]

Почитайте, как происходит демонизация. Вкратце:

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

Здесь не происходит double fork, а top отслеживает лишь наличие процесса и не может получить его код выхода.

ну можно сделать coproc и wait в bash'е, если вам этого так уж хочется.

можете и обернуть демон в обёртку, которая будет сохранять где-то exit status, раз уж вам он так нужен.

Всё это можно сделать и без systemd, одним bash'ем, если есть такая необходимость. Я не очень понимаю, какие плюсы даёт systemd?

PS: да, если уж продолжать демагогию, тогда скажите: как в systemd конфиге сделать ассоциативный массив? Зачем? А вот ХОЧУ. Вы хотите exit status, почему я не могу хотеть ассоциативного массива?

[Hephaestus]

Я не очень понимаю, какие плюсы даёт systemd?

Я тоже не понимаю. И боюсь, что по сути не даёт никаких.
Разве что горе-админам, не осилившим bash. Им будет легче, да. До поры, до времени.

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

[eddy]

Именно потому, что нужность под сомнением.

Лучше в таких случаях не сомневаться, а посылать "в спину". Пока оно не будет адекватным конкурентом sysvinit, про него и говорить нельзя!

[Hephaestus]

Лучше в таких случаях не сомневаться, а посылать "в спину". Пока оно не будет адекватным конкурентом sysvinit, про него и говорить нельзя!

Жаль, что Леннарт и дистростроители думают иначе.

[eddy]

Лучше в таких случаях не сомневаться, а посылать "в спину". Пока оно не будет адекватным конкурентом sysvinit, про него и говорить нельзя!

Жаль, что Леннарт и дистростроители думают иначе.

Жаль. Хорошо еще, что пока не все "дистростроители" сошли с ума. Есть еще и нормальные.

[alv]

Именно потому, что нужность под сомнением.

Леннарт и дистростроители думают иначе.

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

[Hephaestus]

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

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

А во-вторых, для тех разработчиков, которых тут среди форумчан, имеющих к этому отношение, принято называть быдлокодерами

Ну, им-то даже systemd не поможет. И даже два systemd не помогут.

Почему-то мы должны верить, что они будут делать это лучше.

Вот я и говорю, им ничего не поможет.

[Hephaestus]

Леннарту по должностной инструкции положено - ему за это жалованье платят.

Он чином от ума избавлен... (с)

[serzh-z]

Наблюдаю тут и радуюсь - какая классная у вас команда получилась: fflatx, eddy, alv, drBatty - один крутит, другой набрасывает, а третий морально подбодряет. =) Ах, да, а четвёртый больше бездельничает и даёт глупые советы. =)

[Rootlexx]

спасибо конечно. Вот только я не понимаю, зачем мне это?

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

можете и обернуть демон в обёртку, которая будет сохранять где-то exit status, раз уж вам он так нужен.

Всё это можно сделать и без systemd, одним bash'ем, если есть такая необходимость.

Я объяснил, почему нельзя. Ну хорошо, раз вы настаиваете, я набросал простейший демон:

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

#include <stdlib.h>
#include <errno.h>
#include <error.h>
#include <time.h>
#include <unistd.h>

int main()
{
    // Create the first child process
    pid_t child_pid = fork();

    if (child_pid < 0)
        error(EXIT_FAILURE, errno, "cannot fork");

    // Exit the parent process
    if (child_pid)
        return EXIT_SUCCESS;

    // Create new session to disconnect from the controlling terminal
    pid_t sid = setsid();

    if (sid < 0)
        error(EXIT_FAILURE, errno, "cannot create a new session");

    // Now create the second child to stop being a session leader
    child_pid = fork();

    if (child_pid < 0)
        error(EXIT_FAILURE, errno, "cannot fork");

    // Exit the first child
    if (child_pid)
        return EXIT_SUCCESS;

    /*
     * The real daemon code starts here.
     */

    // Wait 60 seconds
    sleep(60);

    // Exit with random non-zero exit status within range [1, 10]
    srand(time(NULL));
    return rand() % 10 + 1;
}

Он делает double fork, как я описывал ранее, а его основной процесс просто ожидает минуту, а затем завершается со случайным ненулевым кодом выхода из сегмента [1, 10]. Попробуйте написать вашу обёртку и узнать реальный код выхода.

Я не очень понимаю, какие плюсы даёт systemd?

Возьмём приведённый выше демон. Для его запуска я написал сложнейший сервис-файл:

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

[Service]
Type=forking
ExecStart=/home/liveuser/kamikadzed

Теперь поэкспериментируем.

root

[root@localhost liveuser]# systemctl status kamikadze.service kamikadze.service Loaded: loaded (/etc/systemd/system/kamikadze.service; static) Active: inactive (dead) [root@localhost liveuser]# systemctl start kamikadze.service [root@localhost liveuser]# systemctl status kamikadze.service kamikadze.service Loaded: loaded (/etc/systemd/system/kamikadze.service; static) Active: active (running) since Wed 2014-03-05 14:32:05 EST; 2s ago Process: 3098 ExecStart=/home/liveuser/kamikadzed (code=exited, status=0/SUCCESS) Main PID: 3100 (kamikadzed) CGroup: /system.slice/kamikadze.service └─3100 /home/liveuser/kamikadzed Mar 05 14:32:05 localhost systemd[1]: Started kamikadze.service. [root@localhost liveuser]# systemctl status kamikadze.service kamikadze.service Loaded: loaded (/etc/systemd/system/kamikadze.service; static) Active: failed (Result: exit-code) since Wed 2014-03-05 14:33:05 EST; 32s ago Process: 3098 ExecStart=/home/liveuser/kamikadzed (code=exited, status=0/SUCCESS) Main PID: 3100 (code=exited, status=9) Mar 05 14:32:05 localhost systemd[1]: Started kamikadze.service. Mar 05 14:33:05 localhost systemd[1]: kamikadze.service: main process exited, code=exited, status=9/n/a Mar 05 14:33:05 localhost systemd[1]: Unit kamikadze.service entered failed state. [root@localhost liveuser]#

Как видите, узнать код выхода процесса демона не составило труда, равно как и узнать, когда он завершился.
Заменим теперь в коде последний return на raise(SIGSEGV) - то есть по прошествии минуты демон завершится из-за ошибки сегментирования.

root

[root@localhost liveuser]# systemctl start kamikadze.service [root@localhost liveuser]# systemctl status kamikadze.service kamikadze.service Loaded: loaded (/etc/systemd/system/kamikadze.service; static) Active: active (running) since Wed 2014-03-05 14:36:44 EST; 50s ago Process: 3144 ExecStart=/home/liveuser/kamikadzed (code=exited, status=0/SUCCESS) Main PID: 3146 (kamikadzed) CGroup: /system.slice/kamikadze.service └─3146 /home/liveuser/kamikadzed Mar 05 14:36:44 localhost systemd[1]: Started kamikadze.service. [root@localhost liveuser]# systemctl status kamikadze.service kamikadze.service Loaded: loaded (/etc/systemd/system/kamikadze.service; static) Active: failed (Result: signal) since Wed 2014-03-05 14:37:44 EST; 5s ago Process: 3144 ExecStart=/home/liveuser/kamikadzed (code=exited, status=0/SUCCESS) Main PID: 3146 (code=killed, signal=SEGV) Mar 05 14:36:44 localhost systemd[1]: Started kamikadze.service. Mar 05 14:37:44 localhost systemd[1]: kamikadze.service: main process exited, code=killed, status=11/SEGV Mar 05 14:37:44 localhost systemd[1]: Unit kamikadze.service entered failed state. [root@localhost liveuser]#

да, если уж продолжать демагогию, тогда скажите: как в systemd конфиге сделать ассоциативный массив? Зачем? А вот ХОЧУ. Вы хотите exit status, почему я не могу хотеть ассоциативного массива?

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

[eddy]

Наблюдаю тут и радуюсь - какая классная у вас команда получилась: fflatx, eddy, alv, drBatty - один крутит, другой набрасывает, а третий морально подбодряет. =) Ах, да, а четвёртый больше бездельничает и даёт глупые советы. =)

А serzh-z клоуничает, выдавая желаемое за действительное.

[Kopilov]

А serzh-z клоуничает, выдавая желаемое за действительное.

Зато Rootlexx пытается открыть троллям их красные глаза.

[eddy]

А serzh-z клоуничает, выдавая желаемое за действительное.

Зато Rootlexx пытается открыть троллям их красные глаза.

Я уж не знаю, что он там пытается. Знаю точно: в обозримом будущем я на всякие systemd переходить не собираюсь. Ну, а если годиков через 3-5 оно станет юзабельным, что ж — возможно.

[alv]

Наблюдаю тут и радуюсь - какая классная у вас команда получилась: fflatx, eddy, alv, drBatty - один крутит, другой набрасывает, а третий морально подбодряет. =) Ах, да, а четвёртый больше бездельничает и даёт глупые советы. =)

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

[drBatty]

Ну, им-то даже systemd не поможет.

почему? BG быдлокодерам всегда помогал -- очень удобно валить все свои косяки на "кривой и глючный маздай".

[drBatty]

Наблюдаю тут и радуюсь - какая классная у вас команда получилась: fflatx, eddy, alv, drBatty - один крутит, другой набрасывает, а третий морально подбодряет. =) Ах, да, а четвёртый больше бездельничает и даёт глупые советы. =)

я правильно понимаю, что технических аргументов у вас не осталось, и вы переходите на личность?

[drBatty]

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

потому что демон не рассчитан на systemd, и его код возврата имеет смысл лишь тогда, когда он не смог запустится. Т.е. демон рассчитан на то, что
1. init-скрипт его запускает
2. если в п1 была ошибка, то демон уведомляет администратора об аварии(например кодом возврата)
3. далее демон работает самостоятельно
как раз двойной форк и нужен для того, что-бы отвязаться от того, от чего его запустили. Если вы его всё равно завяжите, то разработчикам придётся делать тройной форк, дабы ваш systemd думал, что контролирует сервис, но на самом деле он будет контролировать обманку. Что-бы этот ваш systemd НЕ глючил и не лез туда, где он не нужен(по мнению разработчика демона).

Он делает double fork, как я описывал ранее, а его основной процесс просто ожидает минуту, а затем завершается со случайным ненулевым кодом выхода из сегмента [1, 10]. Попробуйте написать вашу обёртку и узнать реальный код выхода.

демон НЕ должен завершаться. Он должен работать. Работать до тех пор, пока не получит сигнал завершения. А когда получит -- должен завершится. Код возврата тут тупо неуместен. Если вы написали демон, который отвязывается от того, что его запустило, то извольте объяснить:
1. зачем он отвязывается от того, что его запустило?
2. зачем он отправляет тому, что его запустило коды ВОЗВРАТА?

Как видите, узнать код выхода процесса демона не составило труда

да. ОК. И что с ним теперь делать? Какой смысл имеет код возврата демона, который не хочет никуда возвращаться? Или ваш демон делал double fork понарошку, а он хочет, да?

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

а какой код возврата будет у SIGSEGV?

Зато Rootlexx пытается открыть троллям их красные глаза.

ага. Усиленно деля на ноль. Да, это не нужно делать.

[Hephaestus]

Наблюдаю тут и радуюсь - какая классная у вас команда получилась

Нравится? Присоединяйтесь.
Я уже вышел из того возраста (подросткового), когда с энтузиазмом хватаешься за всё новое и ставишь себе на комп все подряд супер-пупер-фичастые штуки, все, какие появляются (даже сомнительного происхождения).
Полагаю, что drBatty , тоже уже вышел из этого возраста, а уж alv - тем более.
eddy, который несколько младше меня, вроде как тоже уже повзрослел (судя по тому, что не пошел тупо за дистростроителями, а принял решение сам).
Так что компания и впрямь подобралась неплохая.
Милости просим к нам, serzh-z .

[serzh-z]

Я уж не знаю, что он там пытается. Знаю точно: в обозримом будущем я на всякие systemd переходить не собираюсь. Ну, а если годиков через 3-5 оно станет юзабельным, что ж — возможно.

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

я правильно понимаю, что технических аргументов у вас не осталось, и вы переходите на личность?

Всё верно. Почти все свои аргументы я уже привёл выше, в ответ увидел лишь эмоции. Теперь моя очередь троллить.

Милости просим к нам, serzh-z .

Спасибо, не могу, я всё ещё в подростковом возрасте. Негоже мне с такой достойной компанией на одной стороне быть.

[drBatty]

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

вообще-то не только. Вы мой пост читали? Прочитайте: Переход Ubuntu на Systemd

Есть возражения? Нет? Не нужно демагогии.

Всё верно. Почти все свои аргументы я уже привёл выше, в ответ увидел лишь эмоции. Теперь моя очередь троллить.

аргументы я вижу только у Rootlexx'а, вы до такого не опускаетесь.

я всё ещё в подростковом возрасте.

живость мышления конечно хорошо, скажу по секрету, я развиваю в себе это полезное качество, что-бы не стать ретроградом и луддитом. Но таки трезвость мышления терять тоже не следует. "Просто прогресс" не всегда хорошо. И даже не всегда это именно прогресс. Не следует забывать про то, что регресс и деградация -- тоже может быть НОВЫМ. Мало того, история учит, что обычно оно так и бывает, она по спирали движется, и жрёт свой хвост.

[Hephaestus]

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

Ну не совсем.
Вот выше den_beckett поделился воспоминаниями - вроде как недоволен. И alv тоже как-то восторгов не выражал.
А ведь они не с морозу пришли - устанавливали, пробовали, вникали, изучали документацию... И тем не менее, не понравилось. Я со своей стороны всю тему пытаюсь понять, зачем бы мне понадобилась такая штука как systemd - и не нахожу в ней острой необходимости. Ну никак. Моя система прекрасно обходится без неё.
Поэтому усилия, потраченные на изучение документации, установку, настройку, наблюдение на предмет, всё ли работает так, как нужно, решение тех задач, которые в systemd из коробки не предусмотрены - все эти усилия с вероятностью 99,9% будут потрачены впустую. В самом лучшем случае получится так же как было, в худшем - окажется хуже, чем было.
Скажите, Вы водите автомобиль?
Вот представьте себе, Вы ездите на своем хорошем автомобиле (мерседесе) несколько лет. Знаете его вдоль и поперек. Вас всё устраивает.
И тут вдруг Вам говорят: К вашему автомобилю нужен прицеп. Причём суперприцеп. Что? Зачем? Мне и так нормально, у меня есть багажник.
Нет, у Вас будет суперприцеп, и все остальные автомобили тоже будут с суперприцепами.
Но ведь у некоторых автомобилей уже есть обычный прицеп. Поэтому, чтобы оправдать нужность суперприцепа, его будут прицеплять к автомобилю спереди, а не сзади. Поэтому Вам придётся переучиваться ездить - это раз,
переоборудовать свой автомобиль соответствующим образом - это два, и три - никого не волнует, устраивает это Вас или нет. Изобретатель суперприцепа протолкнул своё изобретение во все дыры. При этом да, возможно суперприцеп принесёт какую-то пользу. Но беда в том, что для этого хватило бы и обычного прицепа. Без всяких затрат, потому что он уже есть.
Думаю, ясно, что под автомобилем подразумевается дистрибутив, а под суперприцепом - systemd.
Да, для меня он выглядит именно так: никчемный прицеп, да ещё спереди. И ничего, кроме затрат на освоение и устранение появившихся неудобств я пока предвидеть не могу.

Спасибо, не могу, я всё ещё в подростковом возрасте. Негоже мне с такой достойной компанией на одной стороне быть.

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

[Rootlexx]

Он делает double fork, как я описывал ранее, а его основной процесс просто ожидает минуту, а затем завершается со случайным ненулевым кодом выхода из сегмента [1, 10]. Попробуйте написать вашу обёртку и узнать реальный код выхода.

демон НЕ должен завершаться. Он должен работать.

Не уводите в сторону. Вы утверждали, что можете поймать код выхода демона:

ну можно сделать coproc и wait в bash'е, если вам этого так уж хочется.

можете и обернуть демон в обёртку, которая будет сохранять где-то exit status, раз уж вам он так нужен.

Всё это можно сделать и без systemd, одним bash'ем, если есть такая необходимость.

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

Как видите, узнать код выхода процесса демона не составило труда

да. ОК. И что с ним теперь делать? Какой смысл имеет код возврата демона, который не хочет никуда возвращаться? Или ваш демон делал double fork понарошку, а он хочет, да?

Double fork демон делает для того, чтобы уйти в фон и отвязаться от управляющего терминала. Однако после этого он становится дочерним процессом init, для передачи которому информации о причине завершения работы и может использоваться код выхода. Так как помимо systemd есть и ещё системы инициализации, принимающие во внимание эту информацию (например, launchd, upstart), это вполне имеет смысл.

а какой код возврата будет у SIGSEGV?

В соответствующем байте кода выхода будет номер сигнала, приведшего к завершению процесса. В данном случае - 11. См. man 2 wait.

[serzh-z]

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

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

[den_beckett]

Ну не совсем.
Вот выше den_beckett поделился воспоминаниями - вроде как недоволен. И alv тоже как-то восторгов не выражал.
А ведь они не с морозу пришли - устанавливали, пробовали, вникали, изучали документацию... И тем не менее, не понравилось. Я со своей стороны всю тему пытаюсь понять, зачем бы мне понадобилась такая штука как systemd - и не нахожу в ней острой необходимости. Ну никак. Моя система прекрасно обходится без неё.

Справедливости ради могу сказать, что я не могу быть полностью объективен - мое восприятие systemd отравлено методами, которыми его внедряли в используемых мной дистрах, прежде всего в Арче, и десятками срачей с малолетними фанбоями.
В принципе, многие идеи лежащие в основе, разумны и прогрессивны, но вот реализация... Опять же, и методы. Оно во-первых, сырое, до сих пор, хотя самые детские баги уже пофикшены. Во-вторых, оно явно не всем нужно. И в третьих, оно слишком много на себя берет. Я бы куда как меньше возражал, если бы это был бы только инит. Но systemd далеко не только инициализацией и управлением процессами занимается, а лезет вовсюда, _разрушая_ и заменяя собой работающие и отлаженные годами механизмы, очень, очень напоминая при том раковую опухоль. И вот это уже мне не нравится ни в коем разе.
А так да, штука любопытная. Может, годиков через пять-шесть ее и допилят до юзабельного состояния. Вот только быть ее принудительным тестером я не хочу, внезапно. Я ставил его еще когда он только появился в тестинге Арча, а то и раньше, из АУРа, не помню уже за давностью лет. Мне оно тогда показалось интересным и перспективным, но сырым в стадии "пре-пре-альфа". Но когда его стали впихивать принудительно и безальтернативно, поливая инакомыслящих помоями и ругательствами, я ушел сначала на initscripts-fork, а потом на openrc. Сейчас периодически качаю Федору и щупаю в виртуалке - как оно там. И результат меня не радует, несмотря на допилку и стабилизацию. Эта штука разрушает старый добрый Линукс, превращая его во что-то виндообразное. Дык одна В-нда у меня и так есть, зачем мне вторая? У меня уже есть система непрозрачная, считающая себя умнее меня и "знающая", что мне нужно и что для меня лучше, где все системные компоненты прибиты гвоздями. И вторая такая мне не нужна, я и от первой переидически подумываю избавиться, именно по этим причинам, на проприетарность и платность мне, в общем, плевать.

ЗЫж. Кстати, кто знает, что там слышно по поводу дебореферендума? Будет чертовски обидно, если кучка засланцев решит судьбу такого большого и важного для экосистемы opensource'а проекта.

[drBatty]

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

того, который отвязался конечно можно только init'ом поймать. Но это "не в сторону". Раз демон отвязался, значит он не хочет выполняться в терминале и выдавать какие-то коды возврата. Он не возвращается.

Как это происходит с systemd, я показал.

и я не сомневаюсь, что в новом Gnome начнут возвращать какие-то коды в init. Что-бы его нельзя было без systemd юзать. Других применений я не вижу.

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

что же это за информация?