Дружище, как раз требование к тому, что всё должен делать демон
(включая чудесные танцы с даблфорком и сетсидом, ручным управлением
пидфайлом, cd в /, переоткрытием стандартных I/O-стримов в /dev/null),
появилось банально из-за того, что в своё время вот это всё придумали
в виде костыля для изготовления процессов, которые могут работать
в фоне (уверен, Вы читали Read Book, и вычитали оттуда, что daemon
это портмоне от Disk And Execution MONitor).То есть вместо того, чтобы придумать систему управления такими фоновыми
процессами, разработали систему костылей для превращения обычных
процессов в фоновые.
В принципе, если смотреть на это как на хак, то это красивый хак,
чоужтам, но если смотреть на это с точки зрения архитектуры,
то это конструкция из навоза и палок.
А чтобы прочувствовать это всё лучше, стОит попробовать написать
программу, от которой Вам бы хотелось, чтоб она и интерактивно
на Вашей консоли, и в фоне работала нормально. Так вот Вы вдруг
внезапно обнаружите, что объём потребных для этого приседаний
ненормально высок. И вдруг найдёте, что даже написали libslack,
чтобы не выписывать указанные приседания самостоятельно.
А потом Вы поймёте, что на самом деле куда логичнее просто делать
так, что у Вас есть обычная программа, и супервизор, который её
способен тривиально "обернуть", чтобы сделать из неё демона.
Добро пожаловать в http://www.libslack.org/daemon/ , runit и т.п.
Теперь ещё стоит подумать о том, а как, например, контролировать
ресурсы системы, которые отжираются всей иерархией процессов с
одним каким-то демоном "в корне" — например, с веб-сервером или
RPC-сервером. SYS V init не решает эту проблему вообще никак,
и не может.
Ну, и остаётся сделать один маленький шажок — мысленно объединить
эти две идеи, и понять, что полноценный супервизор это не NIH-синдром,
это реально удобно — для тех, кому работать надо, а не скилл
баш-шиткодинга прокачивать по вечерам после универа.
Да, *реализация* systemd вызывает ряд вопросов (у кого-то — массу вопросов),
но необходимость в такой штуке давно видна, а реально работающих
(за пределами локалхоста) альтернатив — нет, к сожалению.
Кстати, камрад Russ Allbery из Дебиана описал ситуацию предельно взвешенно
и спокойно, рекоммендую: https://lists.debian.org/debian-devel/2016/08/msg00604.html
