[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Управлениесервисамибезотносительно sysvinit/upstart/systemd



Артём Н. <artiom14 <at> yandex.ru> writes:
> При желании (я сам пока не читал):
> man 7 bootup
> man 7 daemon
> 

daemon(7) - интересный материал!

> > Я бы просто по старинке sysvinit написал бы и не
> разбирался. Они все дергают
> > /etc/init.d/rc в конце концов или как то эмулируют его работу...
> >
> > В общем нужно адаптироваться к новому окружению ((
> >
> Вообще, я не админ, мне не требуются возможности,
> которые предоставляет system.d, но по-моему система дурная...
> Излишне сложно и много напихано, при том, что старое
> вполне работало и не требовало дополнительного изучения.
> Кому-то нравится, но "что-то не то" (зачем, например
> контроль за системой инициализации по D-Bus?).
> 

Зачем контроль кажись рассказано тут:

http://ewontfix.com/15/

Нужен триггер, который бы рассказывал что сервис уже функционирует (через
sd_notify(3) или DBus - так написано в daemon(7)). Требование
WantedBy/RequiredBy/Wants/Requires (т.е. зависимости) работает если сервис
передаcт сообщение о готовности (так что зависимые сервисы гарантироано
смогу работать с зависимостями).

В статье критикуется способ бинарного связывания через sd_notify(3) или DBus.

Полнее о вариантах и механизмах отслеживания запуска в SYSTEMD.SERVICE(5)
поиском по Type=

Тут https://sourceware.org/ml/libc-alpha/2014-02/msg00738.html и в статье
предлагается следить за созданием файла (pid-файл - классический случай) или
открытием порта. systemd такое не поддерживает, для Type=fork отслеживает
смерть родителя (ребенок становится демоном после форка).

Итого systemd НЕ МОЖЕТ ГАРАНТИРОВАНО КОРРЕКТНО СТАРТОВАТ СИСТЕМУ, нужно всем
важным/полезным сервисам следовать требованиям systemd по внедрению
поддержки (то ли бинарно связаться через sd_notify(3), то ли с DBus, то ли
принимать спец. сокет от systemd (наверно через argv, не разобрался)).

Другие приколы от systemd - предлагают демонам писать не в SYSLOG(3)
(реализация в LIBC ?), а в fprintf(stderr, ...), stderr демону не закрывать,
уровни логгирования метить префиксом "<N>...".

Что я персонально вижу - это навязывание стиля оформления приложения,
связывание с их решением - без каких либо попыток быть НЕВМЕШАБЕЛЬНЫМИ.

Люди пишут что systemd это инструмент RedHat еще больше захватать рынок Linux.

> К сведению:
> packages.debian.org/jessie/systemd-sysv
> https://wiki.debian.org/systemd
> 

Тут обычно полнее:

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

У Debian wiki проблемы с лицензированием контента (из-за чего архив незя
запакетировать, если бы она была достаточно полезной) и мало желающих
править странички.

Reply to: