Який правильний спосіб перезапустити залежні служби під час встановлення пакета?

Я створюю конфігураційний пакет і хочу зупинити та перезапустити служби, на конфігурацію яких впливає. Зараз я використовую service [stop|restart]в {pre,post}{inst,rm}шляху. Я десь читав у запитанні, що invoke-rc.dце правильний шлях, оскільки він шанує вподобання користувачів щодо послуги. Однак я не зміг знайти жодних вказівок з цього приводу. Хтось знає про такі вказівки? Або є якісь поради щодо того, який спосіб вибрати? Пакет використовується для внутрішнього використання, і, ймовірно, буде лише 14.04 протягом наступних двох років. Однак я хотів би залишити якомога більш чистий стан для свого наступника, про це також systemdі в моїх думках.

На invoke-rc.dчоловіковій сторінці :

Весь доступ до скриптів init сценаріями технічного обслуговування пакунків Debian повинен здійснюватися через invoke-rc.d .

З Посібника з політики Debian, Розділ 9, Розділ 3.3 :

Обслуговувачі повинні використовувати рівень абстракції, що надається програмами update-rc.d та invoke-rc.d, для роботи з initscripts у скриптах своїх пакетів, таких як postinst, prerm та postrm.

...

Сценарії підтримки пакета повинні використовувати invoke-rc.d для виклику /etc/init.d/* initscripts, а не викликати їх безпосередньо.

Debian використовує sysv-initта перейде безпосередньо на systemd, і я думаю, що посібник з політики буде оновлений вчасно, на який слід посилатися systemctl. Однак, в чому я не впевнений, це таке: чи слід використовувати invoke-rc.dзамість service? Я можу сказати, dpkgщо мене цікавлять деякі файли (через тригери), тож чи є спосіб сказати, dpkgщо мене цікавлять і деякі сервіси, і я можу dpkgзробити перезавантаження / перезавантаження?

Для уточнення: я не пишу сценаріїв init. Я надаю пакет з конфігурацією для інших програм, таких як Puppet, NTP тощо, тому я зупиняюсь і перезапускаю відповідні служби в скриптах.

Ось , наприклад, є Docker питання про invoke-rc.dпроти service. Питання досі залишається відкритим: одна людина, можливо, обслуговуючий персонал, коментує, що їм напевно цікаво зробити це правильно - очевидно, ніхто з нас не впевнений, що це таке. (Моє запитання не залежить від цього питання.)

Я б продовжував використовувати сценарії до / після введення,

preinst - Цей сценарій виконується до того, як цей пакунок буде розпакований зі свого архіву Debian (".deb"). Багато сценаріїв "preinst" зупиняють послуги для пакетів, які оновлюються до завершення їх встановлення чи оновлення (після успішного виконання сценарію "postinst").

postinst - Цей скрипт зазвичай завершує будь-яку необхідну конфігурацію пакета foo, як тільки foo був розпакований зі свого архіву Debian (".deb"). Часто сценарії "postinst" просять користувача ввести та / або попередити користувача, що якщо він приймає значення за замовчуванням, він повинен пам’ятати, щоб повернутися назад і повторно налаштувати цей пакет, як це вимагає ситуація. Після цього багато сценаріїв "postinst" виконують будь-які команди, необхідні для запуску або перезапуску послуги після встановлення або оновлення нового пакета.

дивіться - https://www.debian.org/doc/manuals/debian-faq/ch-pkg_basics.en.html

Синтаксис виклику start | stop | restart записується як умовний, див. Https://www.debian.org/doc/debian-policy/ch-opersys.html розділ 9.3.3.2 Запуск incriptscripts

якщо виклик-rc.d> / dev / null 2> & 1; тоді

invoke-rc.d пакет

ще

/etc/init.d/package

фі

тому ...

if which service >/dev/null 2>&1; then
        service package <action>
elif which invoke-rc.d >/dev/null 2>&1; then
        invoke-rc.d package <action>
else
        /etc/init.d/package <action>
fi

і додайте ще один умовний для systemd за потреби;)

Отже, так, правильний спосіб запустити | stop | перезапустити послугу - це відповідним скриптом обгортки (invoke-rc.d / system), коли це можливо, а не викликати скрипт init (/etc/init.d/package) та повернення до сценарію /etc/init.d, коли обгортка недоступна.

Кращий спосіб для системних систем - використовувати deb-systemd-call .