•••

Не, мне systemd в целом симпатичен; понятно, что SysV-style init давно пора на свалку, и systemd в качестве замены всяко лучше, чем какой-нибудь upstart. Но какого ж хрена он не перезагружает юниты автоматически?!

Я всё понимаю, мониторить директории — моветон. Но если я вручную перезагружаю systemd-logind.service, не логично ли заодно перечитать все зависимости?!

У меня UPS специфичный: если драйвер не выгрузить, уходя в suspend, потом очень сложно заставить его работать после пробуждения. Вопрос решается элементарно, давно был написан хук для pm-utils, который при засыпании выгружал драйвер (и upsmon, чтобы не ругался), а при пробуждении запускал обратно. Собственно, именно это я и переносил сегодня на systemd.

На вкуривание того, как организован сон в systemd, ушло минут десять. На понимание того, как писать юниты, которые будут исполнять роль pm-хуков — ещё минут пять.

На отладку — полтора часа!

Потому что после написания юнит надо включить (и в логе это пишется) а потом перезапустить systemd-logind. После правки включённого юнита нужно его снова включить, причём в логе не пишется ничего, а потом, опять же, перезапустить systemd-logind. Понимание того, что в этой последовательности критичен каждый шаг, приходит ой как не сразу…

Системный лог при отладке засыпаний-пробуждений выходит длинный и с кучей повторов; чтобы разобраться, кто за что отвечает при перезапуске, приходится читать подряд… И вот отладил ты ту часть, которая выгружает всё при засыпании, и начал ковырять пробуждение — а в логе после пробуждения ничего нет, будто юнит и не отрабатывает вовсе. Ну да, не отрабатывает, в ExecStop синтаксическая ошибка вышла, вот только сообщение об этом в логе находится где? Правильно, на этапе засыпания! Потому что юнит впервые запущен тогда, и тогда же его парсер тормознул, несмотря на рабочий ExecStart…

В общем, я сегодня очень хорошо понимаю сторонников классического init.