Jaki jest właściwy sposób na ponowne uruchomienie usług zależnych podczas instalacji pakietu?

Tworzę pakiet konfiguracyjny i chciałbym zatrzymać i ponownie uruchomić usługi, których konfiguracja dotyczy. Teraz Używam service [stop|restart]w {pre,post}{inst,rm}drodze. Czytam pytanie gdzieś invoke-rc.dwe właściwy sposób, ponieważ honoruje preferencje użytkownika dotyczące usługi. Nie mogłem jednak znaleźć żadnych wskazówek na ten temat. Czy ktoś zna takie wytyczne? A może masz jakąś radę, którą wybrać? Pakiet jest przeznaczony do użytku wewnętrznego i prawdopodobnie będzie dostępny tylko na 14.04 przez następne dwa lata. Chciałbym jednak pozostawić tak czysty stan, jak to możliwe dla mojego następcy, tak też systemdmyślę.

Od invoke-rc.dstrony man :

Cały dostęp do skryptów inicjujących przez skrypty opiekuna pakietów Debiana powinien odbywać się poprzez invoke-rc.d .

Z Podręcznika Polityki Debiana, Rozdział 9, Rozdział 3.3 :

Opiekunowie powinni korzystać z warstwy abstrakcji dostarczanej przez programy update-rc.d i invoke-rc.d do radzenia sobie ze skryptami initscript w skryptach swoich pakietów, takich jak postinst, prerm i postrm.

...

Skrypty zarządzające pakietami muszą używać invoke-rc.d, aby wywoływać initscripts /etc/init.d/*, zamiast wywoływać je bezpośrednio.

Debian używa sysv-initi przejdzie bezpośrednio do systemd, i przypuszczam, że podręcznik polityki zostanie zaktualizowany w odpowiednim czasie, aby się do niego odwołać systemctl. Nie jestem jednak pewien: czy powinienem użyć invoke-rc.dzamiast service? Mogę powiedzieć dpkg, że jestem zainteresowany niektórymi plikami (za pomocą wyzwalaczy), więc czy istnieje sposób, aby powiedzieć dpkg, że jestem również zainteresowany niektórymi usługami i rozpocząć dpkgrestartowanie / przeładowywanie?

W celu wyjaśnienia: ja nie piszę skrypty startowe. Dostarczam pakiet z konfiguracją dla innych aplikacji, takich jak Puppet, NTP itp., Więc zatrzymuję i ponownie uruchamiam odpowiednie usługi w skryptach.

Oto , na przykład, jest to kwestia o Docker invoke-rc.dvs service. Kwestia jest nadal otwarta, a jedna osoba, prawdopodobnie opiekun, komentuje, że jest zdecydowanie zainteresowana zrobieniem tego we właściwy sposób - najwyraźniej żadne z nas nie jest pewne, co to jest. (Moje pytanie jest niezależne od tego problemu).

Nadal używałbym skryptów inst / post inst,

preinst - Ten skrypt wykonuje się, zanim pakiet zostanie rozpakowany z pliku archiwum Debiana („.deb”). Wiele skryptów „preinst” zatrzymuje usługi dla pakietów, które są aktualizowane aż do zakończenia ich instalacji lub aktualizacji (po pomyślnym wykonaniu skryptu „postinst”).

postinst - Ten skrypt zwykle kończy każdą wymaganą konfigurację pakietu foo po rozpakowaniu foo ze swojego pliku archiwum Debiana („.deb”). Często skrypty „postinst” pytają użytkownika o dane wejściowe i / lub ostrzegają go, że jeśli zaakceptuje wartości domyślne, powinien pamiętać, aby wrócić i ponownie skonfigurować ten pakiet, jak wymaga tego sytuacja. Wiele skryptów „postinst” wykonuje następnie wszelkie polecenia niezbędne do uruchomienia lub ponownego uruchomienia usługi po zainstalowaniu lub aktualizacji nowego pakietu.

patrz - https://www.debian.org/doc/manuals/debian-faq/ch-pkg_basics.en.html

Składnia wywołania start | stop | restart jest zapisana jako warunkowa, patrz https://www.debian.org/doc/debian-policy/ch-opersys.html sekcja 9.3.3.2 Uruchamianie skryptów startowych

jeśli które invoke-rc.d> / dev / null 2> & 1; następnie

pakiet invoke-rc.d

jeszcze

/etc/init.d/package

fi

więc ...

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

i dodaj kolejne warunki dla systemd w razie potrzeby;)

Tak więc, właściwym sposobem na uruchomienie | stop | restartu usługi jest użycie odpowiedniego skryptu opakowania (invoke-rc.d / system), jeśli to możliwe, zamiast wywoływania skryptu init (/etc/init.d/package) i wracając do skryptu /etc/init.d, gdy żadne opakowanie nie jest dostępne.

Lepszym sposobem dla systemów systemowych jest użycie deb-systemd-invoke .