Как правильно перезапустить зависимые службы при установке пакета?
Я создаю пакет конфигурации и хотел бы остановить и перезапустить службы, конфигурация которых затронута. Прямо сейчас я использую 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 для вызова initscripts /etc/init.d/*, а не вызывать их напрямую.
Debian использует sysv-init и перейдет непосредственно к systemd, и я полагаю, что руководство по политике будет своевременно обновлено со ссылкой на systemctl. Однако в чем я не уверен, так это в том, стоит ли мне использовать invoke-rc.d вместо service? Я могу сказать dpkg, что меня интересуют некоторые файлы (с помощью триггеров), поэтому есть ли способ сообщить dpkg, что меня также интересуют некоторые сервисы, и заставить dpkg выполнить перезапуск / перезагрузку?
Чтобы уточнить: Я не пишу сценарии инициализации. Я предоставляю пакет с конфигурацией для других приложений, таких как Puppet, NTP и т. Д., Поэтому я останавливаю и перезапускаю соответствующие службы в сценариях.
Здесь, например, - проблема Докера о invoke-rc.d против service. Вопрос по-прежнему открыт, один человек, вероятно, сопровождающий, комментирует, что он определенно заинтересован в том, чтобы сделать это правильным правильным способом - очевидно, никто из нас не уверен, что это такое. (Мой вопрос не зависит от этого вопроса.)
2 ответа
Я продолжил бы использовать пред/сообщение inst сценарии,
preinst - Этот сценарий выполняется, прежде чем тот пакет будет распакован из его архива Debian (" .deb") файл. Много 'preinst' сценариев останавливают сервисы для пакетов, которые обновляются до их установки или обновления завершается (после успешного выполнения 'postinst' сценария).
postinst - Этот сценарий обычно завершает любую необходимую конфигурацию нечто пакета, как только нечто было распаковано из его архива 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 Рабочих initscripts
если, которые вызывают-rc.d>/dev/null 2> & 1; тогда
еще вызывают-rc.d пакет
/etc/init.d/package
fi
так...
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 при необходимости;)
Так да, надлежащий путь к start|stop|restart сервис с соответствующим сценарием обертки (вызовите-rc.d / система), если это возможно, скорее затем называя init сценарий (/etc/init.d/package) и отступая к/etc/init.d сценарию, когда никакая обертка не доступна.
Лучший путь к systemd системам состоит в том, чтобы использовать deb-systemd-invoke.