[devel] Поддержка systemd в post/preun_service скриптах

[Pavel Shilovsky]

5 февраля 2013 г., 4:14 пользователь Dmitry V. Levin <ldv на altlinux.org> написал:
> On Mon, Feb 04, 2013 at 04:35:26PM +0400, Alexey Shabalin wrote:
>> 4 февраля 2013 г., 16:29 пользователь Pavel Shilovsky написал:
>> > 4 февраля 2013 г., 16:11 пользователь Alexey Shabalin написал:
>> >> 4 февраля 2013 г., 16:02 пользователь Pavel Shilovsky написал:
>> >>> Добрый день!
>> >>>
>> >>> Сейчас работаю над поддержкой и systemd и sysvinit в спеках OpenStack
>> >>> (сейчас там жёстко пробито использование systemd, что делалось на
>> >>> скорую руку). Обнаружил, что для нормальной поддержки обеих систем не
>> >>> хватает того, что скрипты post_service и preun_service умели понимать,
>> >>> что система работает с systemd и вызывали соответствующие команды.
>> >>> Нашёл багу, где аналогичное уже сделано для скрипта service:
>> >>> https://bugzilla.altlinux.org/show_bug.cgi?id=24989
>> >>
>> >> Если Вы заметили, то баг закрыт, т.е. исправлен.
>> >> Больше ничего делать не надо.
>> >> service умеет понимать, зачем этому же учить post/preun_service?
>> >
>> > Скрипты post/preun_service вызывают помимо service команду chckonfig.
>> chkconfig тоже обучен работе с systemd. сервисы успешно регистрируются.

Даже у конфигурации с сервисами, у которых есть и init скрипты и
service скрипты, это не работает должным образом. Например, при
обновлении пакета с изменением service скрипта на машине с systemd, не
перегружается конфигурация сервиса, о чём systemd сообщает, когда
post_service выполняет condrestart запущенного сервиса.

>
> Обучить post/preun_service по аналогии с service все равно нужно для того,
> чтобы проще было поддерживать сервисы, в которых есть service-файлы и
> уже нет init-скриптов.  Но это надо сделать более тонко, чем в
> вышеупомянутом патче.

Согласен, что данная реализация не самая лучшая. Возможно стоит
перенести определение используется ли systemd в системе или нет в
отдельный файл куда-нибудь в /usr/share/service-functions?

-- 
Best regards,
Pavel Shilovsky.