Bug 29925

спасибо, посмотрю.

systemd используется ?

Да. На машинах с sysvinit вроде не замечено такого.

systemd несовместим с SysV init, надо править именно его.

Если хотите использовать совместно с systemd, то придется править php5-fpm-fcgi.
Я не буду добавлять никаких новых параметров в systemd(и в service тоже).

А чего править то ? какая замена service rotate ?

В fedora для таких выкрутасов есть подобное:
%if %{WITH_SYSTEMD}
%attr(640,root,root) %{_unitdir}/auditd.service
%attr(750,root,root) %dir %{_libexecdir}/initscripts/legacy-actions/auditd
%attr(750,root,root) %{_libexecdir}/initscripts/legacy-actions/auditd/resume
%attr(750,root,root) %{_libexecdir}/initscripts/legacy-actions/auditd/rotate
%attr(750,root,root) %{_libexecdir}/initscripts/legacy-actions/auditd/stop
%attr(750,root,root) %{_libexecdir}/initscripts/legacy-actions/auditd/restart
%attr(750,root,root) %{_libexecdir}/initscripts/legacy-actions/auditd/condrestart
%else

а что у нас?

http://en.opensuse.org/openSUSE:Systemd_packaging_guidelines#extra_actions

Т.е. - кто-то должен поддерживать legacy actions для ряда сервисов.
Кто?

Вот аналогичный баг.
https://bugzilla.altlinux.org/show_bug.cgi?id=27568

Если хочется использовать что-то нестандартное в скрипте, то не надо для этого
привлекать service.

ЗЫ: никакие if %{WITH_SYSTEMD} не нужны.

if %{WITH_SYSTEMD} взялся из RedHat'овского спека.
Почему бы нам не сделать так, как у SuSE и RedHat?

service тогда получается вообще не нужен - можно всегда звать initscript напрямую.

Дима, service твой пакет. Что скажешь ?

Антон, ты же прекрасно видишь, что SuSE и RedHat поддерживают %if %{WITH_SYSTEMD} упаковывают одни файлы, и игнорирует другие. Они целиком мигрировали на systemd, и забыли об SysV.
Мы же в ALTLinux поддерживаем обе системы инициализации, одновременно. Мы глобально не заявляли, что отказываемся от SysV.
Я не пойму, что тебе мешает заменить в php5-fpm.logrotate
 /sbin/service php5-fpm rotate >/dev/null
на
 /etc/init.d/php5-fpm rotate >/dev/null
?

То, что я вижу - это RedHat добавил для случая с systemd возможность выполнять произвольные действия для служб.
Очень удобно.

Да, и в их варианте можно будет действительно отказаться от SysVInit скриптов. В нашем - будем таскать с собой пока не реализуем их вариант.

Есть какие-то безумные сложности с тем, что бы сделать как у них ?

(В ответ на комментарий №14)
> То, что я вижу - это RedHat добавил для случая с systemd возможность выполнять
> произвольные действия для служб.
> Очень удобно.
> 
> Да, и в их варианте можно будет действительно отказаться от SysVInit скриптов.
> В нашем - будем таскать с собой пока не реализуем их вариант.
> 
> Есть какие-то безумные сложности с тем, что бы сделать как у них ?

Пришли пожалуйста патч, или ткни пальцем. У меня ощущение, что мы о разном ведем речь.
%if %{WITH_SYSTEMD}
%attr(640,root,root) %{_unitdir}/auditd.service
в спеке используется только на этапе сборки, и то что попало в пакет, то и попало, при установке пакета в систему ничего не проверяется.
Мы же кладем в систему оба файла:
и 
%{_unitdir}/auditd.service
и
%{_initdir}/auditd
А в дальнейшем определяем под чем работает система (/sbin/sd_booted)

посмотри на исходники service из fedora.
строка 9
https://git.fedorahosted.org/cgit/initscripts.git/tree/service?id=initscripts-9.54-1#n9

и дальнейшая обработка ACTIONDIR:
https://git.fedorahosted.org/cgit/initscripts.git/tree/service?id=initscripts-9.54-1#n73

(In reply to comment #14)
> То, что я вижу - это RedHat добавил для случая с systemd возможность выполнять
> произвольные действия для служб.
> Очень удобно.

Не для systemd, а для service в системе под управлением systemd.
Наверное, это удобные костыли, но они от этого не перестают быть костылями,
и каталог у них не просто так получил название initscripts/legacy-actions.

Если "audit rotate" - это публичный интерфейс, то лучше сделать audit-rotate(8).

мне кажется, что service (или systemct) должен выполнять только start, stop,
restart, condrestart, condstop.
Если надо вызвать что-то не стандартное, то при чем тут service?
Запускайте как угодно без service.
Унификация требует жертв, но и приводит к единым стандартам.

Пускай будут удобные костыли, к тому же и service можно назвать костылём. auditd rotate это всего-лишь SIGUSR1, и таких мест есть ещё, не только у меня и не только rotate.

(In reply to comment #18)
> мне кажется, что service (или systemct) должен выполнять только start, stop,
> restart, condrestart, condstop.
> Если надо вызвать что-то не стандартное, то при чем тут service?
> Запускайте как угодно без service.
> Унификация требует жертв, но и приводит к единым стандартам.

service не стоит терять обратную совместимость. Каким бы systemd не был, надо постараться обеспечить одинаковую семантику для service auditd на systemd и на sysvinit, к тому же на первом ещё и всё стандартизировано.

про какую совместимость идет речь?
start|stop и т.п. поддерживаются.
А вот то что в скрипте можно описать абсолютно любую опцию - какая же это совместимость? этого невозможно сделать в рамках systemd - просто нет этого, и все.
Невозможно в /lib/systemd/system/auditd.service придумать что-то еще, там есть только ExecStart и ExecReload.

да, и именно поэтому в /sbin/sevice RedHat и SuSE ввели понятие legacy actions - для того, что бы не ломать совместимость с теми системами, которые ожидают от /sbin/service что-то большее, чем start/stop/status.

logrotate это частный случай. 
Мы же не можем предсказать, какие системы, заточенные на RedHat или SuSE, будут работать с нашим auditd. Поэтому надо постараться обеспечить совмесимость там, где это можно сделать.

Именно поэтому не стоит этого делать у нас.
У нас мантейнеры ленятся просто .service файл подложить, а ты хочешь их еще обязать придумывать для совместимости скрипты в /usr/libexec/initscripts/legacy-action? Ты же этого сам делать не будешь. И я не буду.
Гораздо проще везде где хочется сказать service audit rotate, проще заменить на /etc/rc.d/audit rotate.

(In reply to comment #22)
> да, и именно поэтому в /sbin/sevice RedHat и SuSE ввели понятие legacy actions
> - для того, что бы не ломать совместимость с теми системами, которые ожидают от
> /sbin/service что-то большее, чем start/stop/status.
> 
> logrotate это частный случай. 
> Мы же не можем предсказать, какие системы, заточенные на RedHat или SuSE, будут
> работать с нашим auditd. Поэтому надо постараться обеспечить совмесимость там,
> где это можно сделать.

Ты шутишь?  Как будто мало нам нашего legacy, так ты предлагаешь еще и с RedHat'овским legacy совместимость обеспечивать?
Я думаю, что было бы правильно отрепортить в RedHat, что для таких действий, как audit rotate, нужен нормальный документированный интерфейс.

(In reply to comment #23)
> Именно поэтому не стоит этого делать у нас.
> У нас мантейнеры ленятся просто .service файл подложить, а ты хочешь их еще
> обязать придумывать для совместимости скрипты в
> /usr/libexec/initscripts/legacy-action? Ты же этого сам делать не будешь. И я
> не буду.

Я не буду, это апстрим сделали и положил нужные скриптики в пакет. Мне только в спеке то файлики перечислить.

> Гораздо проще везде где хочется сказать service audit rotate, проще заменить на
> /etc/rc.d/audit rotate.

Гораздо проще вызывать все неподдерживаемые systemctl таргеты из init файла.

(In reply to comment #24)
> (In reply to comment #22)
> > да, и именно поэтому в /sbin/sevice RedHat и SuSE ввели понятие legacy actions
> > - для того, что бы не ломать совместимость с теми системами, которые ожидают от
> > /sbin/service что-то большее, чем start/stop/status.
> > 
> > logrotate это частный случай. 
> > Мы же не можем предсказать, какие системы, заточенные на RedHat или SuSE, будут
> > работать с нашим auditd. Поэтому надо постараться обеспечить совмесимость там,
> > где это можно сделать.
> 
> Ты шутишь?  Как будто мало нам нашего legacy, так ты предлагаешь еще и с
> RedHat'овским legacy совместимость обеспечивать?

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

> Я думаю, что было бы правильно отрепортить в RedHat, что для таких действий,
> как audit rotate, нужен нормальный документированный интерфейс.

ещё в php. Да, и мало ли где это попадётся.

(In reply to comment #26)
> (In reply to comment #24)
> > (In reply to comment #22)
> > > да, и именно поэтому в /sbin/sevice RedHat и SuSE ввели понятие legacy actions
> > > - для того, что бы не ломать совместимость с теми системами, которые ожидают от
> > > /sbin/service что-то большее, чем start/stop/status.
> > > 
> > > logrotate это частный случай. 
> > > Мы же не можем предсказать, какие системы, заточенные на RedHat или SuSE, будут
> > > работать с нашим auditd. Поэтому надо постараться обеспечить совмесимость там,
> > > где это можно сделать.
> > 
> > Ты шутишь?  Как будто мало нам нашего legacy, так ты предлагаешь еще и с
> > RedHat'овским legacy совместимость обеспечивать?
> 
> Так мы и так это делаем, копируя у них systemd.

Я бы не стал утверждать, что systemd - это legacy.

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

С нашим legacy я предлагаю поступать так:
https://bugzilla.altlinux.org/show_bug.cgi?id=27568#c5

> > Я думаю, что было бы правильно отрепортить в RedHat, что для таких действий,
> > как audit rotate, нужен нормальный документированный интерфейс.
> 
> ещё в php. Да, и мало ли где это попадётся.

Согласен, надо репортить это обо всем, что попадется.
А если обучить service этому initscripts/legacy-actions, то никто не будет ничего репортить.

Дима, скажи - зачем репортить, если оно будет работать без дополнительных телодвижений ?

Кстати, идея с initscripts actions ещё хороша тем, что мы явно выделим то, что не работает по дефолту в systemd. 
Иначе так и будет продолжаться - я, например, не планирую использовать systemd на серверных установках.

Сколько приложений не работает в Sisyphus с systemd или работают не так, как надо ?

(In reply to comment #28)
> Дима, скажи - зачем репортить, если оно будет работать без дополнительных
> телодвижений ?

Я понимаю, что заткнуть здесь и сейчас проще.
Но нам следует мыслить системно.

> Кстати, идея с initscripts actions ещё хороша тем, что мы явно выделим то, что
> не работает по дефолту в systemd.

systemd структурирует actions, и это хорошо: каждый action документирован, и ты примерно представляешь себе, чего от него ждать.

initscripts/legacy-actions - это именно то, как оно называется - раньше в initscripts пихали все подряд, и теперь, с переходом на структурированные initscripts actions, это все ранее напиханное приходится подпирать.

> Иначе так и будет продолжаться - я, например, не планирую использовать systemd
> на серверных установках.
> 
> Сколько приложений не работает в Sisyphus с systemd или работают не так, как
> надо ?

Проблема не в systemd, она была всегда, просто благодаря systemd она проявилась.

Еще раз, вариант "просто заткнуть, чтобы работало, как раньше", применительно к auditd, выглядит так:
- запаковать /usr/libexec/initscripts/legacy-actions/auditd/{resume,rotate};
- обучить /sbin/service отправлять все actions, которые не поддерживает systemctl, в /usr/libexec/initscripts/legacy-actions/$SERVICE/$ACTION;
- продолжать использовать "service auditd {resume,rotate}", как будто ничего не случилось, нестандартные actions не документировать.

Вариант исправить системно:
- запаковать /usr/sbin/auditd-{resume,rotate} и документацию к ним;
- исправить пользователей "service auditd {resume,rotate}" на документированный интерфейс "auditd-{resume,rotate}".

Зачем городить дополнительные костыли в виде утилит - прослоек, если есть kill -SIGUSR1 или единая точка входа service ?

Это как раз внесистемный подход.

Ты же сам в https://bugzilla.altlinux.org/show_bug.cgi?id=27568#c5 
сделал костыль вместо утилиты clock-tzset - вызов /etc/init.d/clock tzset

А как быть пользователям, которые привыкли использовать service clock tzset/sync ?

Или скриптам, которые ожидают именно такое поведение от service clock ?

(In reply to comment #30)
> Зачем городить дополнительные костыли в виде утилит - прослоек, если есть kill
> -SIGUSR1 или единая точка входа service ?

Надо ведь еще аккуратно вычислить процесс, которому послать этот сигнал, иначе бы, я думаю, никто бы не запихивал rotate в /etc/init.d/auditd и не создавал бы костыли вида /usr/libexec/initscripts/legacy-actions/auditd/rotate.

> Это как раз внесистемный подход.

service $NAME произвольнаяпоследовательностьбукв - это не единая точка входа, это бардак, который мы все развели, и который надо для начала признать.

А ведь есть уже давно на свете
systemctl kill --signal=SIGUSR1 --kill-who=main auditd.service

Ну а RedHat даже /usr/libexec/initscripts/legacy-actions/auditd/stop пакует!

> Ты же сам в https://bugzilla.altlinux.org/show_bug.cgi?id=27568#c5 
> сделал костыль вместо утилиты clock-tzset - вызов /etc/init.d/clock tzset

$ rpmquery --scripts tzdata
postinstall program: /usr/sbin/tzupdate

$ grep -FA1 'tzset)' /etc/init.d/clock
	tzset)
		action 'Setting timezone information' "$tzupdate"

> А как быть пользователям, которые привыкли использовать service clock
> tzset/sync ?
> 
> Или скриптам, которые ожидают именно такое поведение от service clock ?

Исправляться.

(In reply to comment #31)
> (In reply to comment #30)
> > Зачем городить дополнительные костыли в виде утилит - прослоек, если есть kill
> > -SIGUSR1 или единая точка входа service ?
> 
> Надо ведь еще аккуратно вычислить процесс, которому послать этот сигнал, иначе
> бы, я думаю, никто бы не запихивал rotate в /etc/init.d/auditd и не создавал бы
> костыли вида /usr/libexec/initscripts/legacy-actions/auditd/rotate.

Верно. И как ты предлагаешь делать это в утилите ? Это же будет враппер, который в любом случае будет звать или systemctl или /etc/init.d/auditd.

Придётся для каждого случая копировать код, и я не понимаю почему ты не хочешь сделать это системно.

> 
> > Это как раз внесистемный подход.
> 
> service $NAME произвольнаяпоследовательностьбукв - это не единая точка входа,
> это бардак, который мы все развели, и который надо для начала признать.

Конечно бардак. Но прежде чем его исправлять - нужно выявить все места его проявления и систематизировать из. Может быть там только rotate и нужен ? Ну с некоторым количеством дополнений.

> 
> А ведь есть уже давно на свете
> systemctl kill --signal=SIGUSR1 --kill-who=main auditd.service
> 
> Ну а RedHat даже /usr/libexec/initscripts/legacy-actions/auditd/stop пакует!

Да, я тоже удивился. Видимо всё не так просто в королевстве systemd, если они посылают TERM сигнал процессу другим механизмом.

Или это какие-то заделы на будущее - у них есть resume, с помощью которого можно заставить auditd продолжить писать логи после suspend'а, но вот кода для suspend я не нашёл. 

В идеале auditd не должен никогда прекращать свою работу.

> 
> > Ты же сам в https://bugzilla.altlinux.org/show_bug.cgi?id=27568#c5 
> > сделал костыль вместо утилиты clock-tzset - вызов /etc/init.d/clock tzset
> 
> $ rpmquery --scripts tzdata
> postinstall program: /usr/sbin/tzupdate
> 
> $ grep -FA1 'tzset)' /etc/init.d/clock
>     tzset)
>         action 'Setting timezone information' "$tzupdate"

Тогда зачем ты зовёшь initscript в исправлении этой баги ? ;)

> 
> > А как быть пользователям, которые привыкли использовать service clock
> > tzset/sync ?
> > 
> > Или скриптам, которые ожидают именно такое поведение от service clock ?
> 
> Исправляться.

Они не будут исправляться, пока в RH/SuSE не поменяют поведение service.

Уж коль всё сводится к правке service и всё обсуждение идёт вокруг этого - я переименую ошибку, дабы не терять истории.

(In reply to comment #32)
> (In reply to comment #31)
> > (In reply to comment #30)
> > > Зачем городить дополнительные костыли в виде утилит - прослоек, если есть kill
> > > -SIGUSR1 или единая точка входа service ?
> > 
> > Надо ведь еще аккуратно вычислить процесс, которому послать этот сигнал, иначе
> > бы, я думаю, никто бы не запихивал rotate в /etc/init.d/auditd и не создавал бы
> > костыли вида /usr/libexec/initscripts/legacy-actions/auditd/rotate.
> 
> Верно. И как ты предлагаешь делать это в утилите ? Это же будет враппер,
> который в любом случае будет звать или systemctl или /etc/init.d/auditd.
> 
> Придётся для каждого случая копировать код, и я не понимаю почему ты не хочешь
> сделать это системно.

Поскольку rotate - это нестандартное действие, то все равно будет враппер,
вопрос только в интерфейсе к нему.

> > А ведь есть уже давно на свете
> > systemctl kill --signal=SIGUSR1 --kill-who=main auditd.service
> > 
> > Ну а RedHat даже /usr/libexec/initscripts/legacy-actions/auditd/stop пакует!
> 
> Да, я тоже удивился. Видимо всё не так просто в королевстве systemd, если они
> посылают TERM сигнал процессу другим механизмом.
> 
> Или это какие-то заделы на будущее - у них есть resume, с помощью которого
> можно заставить auditd продолжить писать логи после suspend'а, но вот кода для
> suspend я не нашёл.

Нет, никакой legacy stop там не должен быть нужен, это просто RedHat тормозит.

> В идеале auditd не должен никогда прекращать свою работу.

Тогда будут проблемы с выключением системы, он же держит какие-то ресурсы.

> > > Ты же сам в https://bugzilla.altlinux.org/show_bug.cgi?id=27568#c5 
> > > сделал костыль вместо утилиты clock-tzset - вызов /etc/init.d/clock tzset
> > 
> > $ rpmquery --scripts tzdata
> > postinstall program: /usr/sbin/tzupdate
> > 
> > $ grep -FA1 'tzset)' /etc/init.d/clock
> >     tzset)
> >         action 'Setting timezone information' "$tzupdate"
> 
> Тогда зачем ты зовёшь initscript в исправлении этой баги ? ;)

Не должен бы.  Может, забыл где?

> > > А как быть пользователям, которые привыкли использовать service clock
> > > tzset/sync ?
> > > 
> > > Или скриптам, которые ожидают именно такое поведение от service clock ?
> > 
> > Исправляться.
> 
> Они не будут исправляться, пока в RH/SuSE не поменяют поведение service.

Вряд ли они там используют service clock.

(In reply to comment #34)
> (In reply to comment #32)
> > (In reply to comment #31)
> > > (In reply to comment #30)
> > > > Зачем городить дополнительные костыли в виде утилит - прослоек, если есть kill
> > > > -SIGUSR1 или единая точка входа service ?
> > > 
> > > Надо ведь еще аккуратно вычислить процесс, которому послать этот сигнал, иначе
> > > бы, я думаю, никто бы не запихивал rotate в /etc/init.d/auditd и не создавал бы
> > > костыли вида /usr/libexec/initscripts/legacy-actions/auditd/rotate.
> > 
> > Верно. И как ты предлагаешь делать это в утилите ? Это же будет враппер,
> > который в любом случае будет звать или systemctl или /etc/init.d/auditd.
> > 
> > Придётся для каждого случая копировать код, и я не понимаю почему ты не хочешь
> > сделать это системно.
> 
> Поскольку rotate - это нестандартное действие, то все равно будет враппер,
> вопрос только в интерфейсе к нему.
> 
> > > А ведь есть уже давно на свете
> > > systemctl kill --signal=SIGUSR1 --kill-who=main auditd.service
> > > 
> > > Ну а RedHat даже /usr/libexec/initscripts/legacy-actions/auditd/stop пакует!
> > 
> > Да, я тоже удивился. Видимо всё не так просто в королевстве systemd, если они
> > посылают TERM сигнал процессу другим механизмом.
> > 
> > Или это какие-то заделы на будущее - у них есть resume, с помощью которого
> > можно заставить auditd продолжить писать логи после suspend'а, но вот кода для
> > suspend я не нашёл.
> 
> Нет, никакой legacy stop там не должен быть нужен, это просто RedHat тормозит.

это сделано нарочно. Можешь поинтересоваться у автора, если интересно зачем.

commit e94faad18f13da6acc183e98d51d1a93cdc24c03
Author: sgrubb <sgrubb@03a675c2-f56d-4096-908f-63dba836b7e4>
Date:   Thu May 16 11:03:16 2013 +0000

    Don't use systemctl to stop the audit daemon


> 
> > В идеале auditd не должен никогда прекращать свою работу.
> 
> Тогда будут проблемы с выключением системы, он же держит какие-то ресурсы.

Сложно сказать со 100% уверенностью, но я не думаю что systemd дожидается освобождения всех ресурсов для выключения.

> 
> > > > Ты же сам в https://bugzilla.altlinux.org/show_bug.cgi?id=27568#c5 
> > > > сделал костыль вместо утилиты clock-tzset - вызов /etc/init.d/clock tzset
> > > 
> > > $ rpmquery --scripts tzdata
> > > postinstall program: /usr/sbin/tzupdate
> > > 
> > > $ grep -FA1 'tzset)' /etc/init.d/clock
> > >     tzset)
> > >         action 'Setting timezone information' "$tzupdate"
> > 
> > Тогда зачем ты зовёшь initscript в исправлении этой баги ? ;)
> 
> Не должен бы.  Может, забыл где?

Ты в ошибке как пример привёл /etc/init.d/clock tzupdate

> 
> > > > А как быть пользователям, которые привыкли использовать service clock
> > > > tzset/sync ?
> > > > 
> > > > Или скриптам, которые ожидают именно такое поведение от service clock ?
> > > 
> > > Исправляться.
> > 
> > Они не будут исправляться, пока в RH/SuSE не поменяют поведение service.
> 
> Вряд ли они там используют service clock.

На service clock мир не заканчивается ;)

(In reply to comment #35)
> (In reply to comment #34)
> > (In reply to comment #32)
> > > (In reply to comment #31)
> > > > (In reply to comment #30)
> > > > > Зачем городить дополнительные костыли в виде утилит - прослоек, если есть kill
> > > > > -SIGUSR1 или единая точка входа service ?
> > > > 
> > > > Надо ведь еще аккуратно вычислить процесс, которому послать этот сигнал, иначе
> > > > бы, я думаю, никто бы не запихивал rotate в /etc/init.d/auditd и не создавал бы
> > > > костыли вида /usr/libexec/initscripts/legacy-actions/auditd/rotate.
> > > 
> > > Верно. И как ты предлагаешь делать это в утилите ? Это же будет враппер,
> > > который в любом случае будет звать или systemctl или /etc/init.d/auditd.
> > > 
> > > Придётся для каждого случая копировать код, и я не понимаю почему ты не хочешь
> > > сделать это системно.
> > 
> > Поскольку rotate - это нестандартное действие, то все равно будет враппер,
> > вопрос только в интерфейсе к нему.
> > 
> > > > А ведь есть уже давно на свете
> > > > systemctl kill --signal=SIGUSR1 --kill-who=main auditd.service
> > > > 
> > > > Ну а RedHat даже /usr/libexec/initscripts/legacy-actions/auditd/stop пакует!
> > > 
> > > Да, я тоже удивился. Видимо всё не так просто в королевстве systemd, если они
> > > посылают TERM сигнал процессу другим механизмом.
> > > 
> > > Или это какие-то заделы на будущее - у них есть resume, с помощью которого
> > > можно заставить auditd продолжить писать логи после suspend'а, но вот кода для
> > > suspend я не нашёл.
> > 
> > Нет, никакой legacy stop там не должен быть нужен, это просто RedHat тормозит.
> 
> это сделано нарочно. Можешь поинтересоваться у автора, если интересно зачем.
> 
> commit e94faad18f13da6acc183e98d51d1a93cdc24c03
> Author: sgrubb <sgrubb@03a675c2-f56d-4096-908f-63dba836b7e4>
> Date:   Thu May 16 11:03:16 2013 +0000
> 
>     Don't use systemctl to stop the audit daemon

Либо автор не справился с systemd.kill(5), либо это зверский хак, чтобы обмануть систему зависимостей systemd.

скорее всего вся проблема в зависимостях systemd. 

Как оно ведёт себя, если нужно погасить сервис, на который много чего завязано ? Выключается всё ?
Врятли сам systemd использует legacy actions при shutdown.


Я это всё веду к тому, что костыли будут нужны в любом случае и если мы их размажем по всей системе и каждый придумает свои - лучше от этого никому не будет. Так давай мы эти костыли соберём в одном место, дабы понимать как и что у нас ещё не работает (или работает).

Костыли, интегрированные в систему - становятся архитектурными достижениями ;)

Иначе мы так и будем топтаться на sysvinit вечно. 
Мне вот, например, даже тестировать исправления особо негде - везде sysvinit и всё отлично работает.
А прежде чем переходить, надо вытоптать правила игры.

Кроме применения для собственно legacy actions это решение позволяет сделать еще одну важнейшую вещь — реализовать единую точку управления сервисами.

У нас до внедрения systemd была уникальная фича: для любого сервиса, если надо было что-то с ним сделать, то часто это решалось с помощью service <сервис> <команда>

Реализация этого в виде единого init-скрипта была далеко не идеальным решением, а вынос этих дополнительных команд в отдельные скрипты — удобно и для мантейнера, и для администратора.

service-0.5.26-alt1 -> sisyphus:

* Tue Sep 09 2014 Dmitry V. Levin <ldv@altlinux> 0.5.26-alt1
- preun_service: added chkconfig call in systemd case (closes: #30165).
- service: added legacy-actions support (closes: #29925).
- sd_booted: synced systemd check with libsystemd.

Пожар начался с того, что логи ротатятся, но FPM об этом не узнаёт. В этом смысле ничего не изменилось.

service-0.5.26-alt1 -> t7:

* Tue Sep 09 2014 Dmitry V. Levin <ldv@altlinux> 0.5.26-alt1
- preun_service: added chkconfig call in systemd case (closes: #30165).
- service: added legacy-actions support (closes: #29925).
- sd_booted: synced systemd check with libsystemd.

* Mon May 12 2014 Dmitry V. Levin <ldv@altlinux> 0.5.25-alt1
- service: use is-active as a closer systemd equivalent of
  sysvinit status (closes: #30034).

(In reply to comment #41)
> service-0.5.26-alt1 -> t7:

Repository Robot is too primitive.

исправлено в php5-fpm-fcgi-5.5.21.20150121-alt1