Время от времени от крона приходят такие письма: ============================================================ Anacron <root@evg-krsk.dyndns.org> (Sun, 30 Mar 2014 13:16:16 +0800) (inbox year_2014) Subject: Anacron job 'cron.daily' To: root@evg-krsk.dyndns.org Date: Sun, 30 Mar 2014 13:16:16 +0800 Unknown operation 'rotate'. error: error running shared postrotate script for '/var/log/php5-fpm/*.log ' ============================================================ первое такое письмо мне пришло 28.10.2013.
спасибо, посмотрю.
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
