systemd - это отчасти аналог Service Control Manager ?

Про взаимодействие с графикой (если это не о systemd/user) будешь спрашивать лет через 5, когда наконец-то запилят что-то на основе wayland как system compositor.

Интерфейс для демонов с systemd не нужен: можно написать что угодно, systemd сам демонизирует, переведёт stdout/stderr в journald и будет следить за перезапуском.

интерфейс не нужен

да? а как сервисы узнаЮт, что им пора останавливаться (например перед выключением машины)?

SIGTERM.

да, спасибо. А описание интерфейса есть, причем двух - старого и нового:
http://www.freedesktop.org/software/systemd/man/daemon.html

О, кстати, классная дока. Не замечал её раньше. Спасибо.

// sudo cast Stahl — к нашему давнему разговору о демонизации

Интерфейс для демонов с systemd не нужен: можно написать что угодно, systemd сам демонизирует

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

Ага, вижу.

либо демонизироваться через двойной форк

Эмм. Раньше других вариантов особо не было.

Раньше любая система инициализации срать хотела на количество форков.
Системд — первая на моей памяти, когда это стало критично.
Я уж не говорю о том, что сама концепция двойного форка сродни дублированию rm «чтобы наверняка».

Я уж не говорю о том, что сама концепция двойного форка сродни дублированию rm «чтобы наверняка».

Остальное — ладно, но тут я всё-таки объективно не соглашусь.

http://stackoverflow.com/a/881434/857932

Системд — первая на моей памяти, когда это стало критично.

upstart в убунте тоже нуждается в указании форков. Там даже в доке есть скриптик по кол-ву форков. Иначе оно другой PID всосёт и конец всему произойдет, только ребут делать, ибо просто так удалить оттуда неверный PID нельзя.

http://upstart.ubuntu.com/cookbook/#expect

А ещё сервисы могут взаимодействовать с десктопом (создавать окна).

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

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

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

Ну как бы для этого должна быть ОТДЕЛЬНАЯ программулина, висящая в трее например. И не надо впиливать несвойственные фичи в службы.

почему она должна быть отдельной? Потребность инициации взаимодействия от сервиса есть? - есть!

Ну как бы для этого должна быть ОТДЕЛЬНАЯ программулина, висящая в трее например. И не надо впиливать несвойственные фичи в службы.

К стати abrtd так и работает.

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

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

Хотя, в тёмные времена, когда мне приходилось иметь дело с 1С 7, службе приходилось давать такое право, потому что даже COM-сервер 1С 7 был такой кривой, что требовал оконности для запуска. :)

интересно, а если на терминалке 2 узверя залогинено, там шо, сервис разрывало на части? :)

Честно говоря не проверял. :)