Qual é a maneira correta de reiniciar serviços dependentes durante a instalação do pacote?

Estou criando um pacote de configuração e gostaria de parar e reiniciar os serviços cuja configuração é afetada. Agora eu estou usando o service [stop|restart]em {pre,post}{inst,rm}forma. Eu li em uma pergunta em algum lugar que invoke-rc.dé o caminho certo , porque honra as preferências do usuário sobre um serviço. No entanto, não encontrei nenhuma orientação sobre isso. Alguém conhece essas diretrizes? Ou tem algum conselho sobre qual caminho devo escolher? O pacote é de uso interno e provavelmente será apenas para 14.04 nos próximos dois anos. No entanto, gostaria de deixar um estado o mais limpo possível para o meu sucessor, o que também systemdestá em minha mente.

Na invoke-rc.dpágina do manual :

Todo acesso aos scripts init pelos scripts de manutenção dos pacotes Debian deve ser feito através do invoke-rc.d .

No Manual de Políticas Debian, Capítulo 9, Seção 3.3 :

Os mantenedores devem usar a camada de abstração fornecida pelos programas update-rc.d e invoke-rc.d para lidar com initscripts nos scripts de seus pacotes, como postinst, prerm e postrm.

...

Os scripts do mantenedor do pacote devem usar invoke-rc.d para chamar os initscripts /etc/init.d/*, em vez de chamá-los diretamente.

O Debian está usando sysv-inite mudará diretamente para systemd, e eu suponho que o manual de políticas será atualizado no devido tempo para referência systemctl. No entanto, o que tenho dúvidas é: devo usar em invoke-rc.dvez de service? Eu posso dizer dpkgque estou interessado em alguns arquivos (por meio de gatilhos), então existe uma maneira de dizer dpkgque também estou interessado em alguns serviços e dpkgfazer a reinicialização / recarregamento?

Para esclarecer: não estou escrevendo scripts de inicialização. Estou fornecendo um pacote com configuração para outros aplicativos, como Puppet, NTP, etc., então paro e reinicio os serviços correspondentes nos scripts.

Aqui , por exemplo, é uma questão Docker sobre invoke-rc.dvs service. O problema ainda está aberto, com uma pessoa, provavelmente um mantenedor, comentando que eles definitivamente estão interessados ​​em fazer isso da maneira certa - claramente, nenhum de nós tem certeza do que é isso. (Minha pergunta é independente desse problema.)

Eu continuaria usando os scripts pré / pós-inst,

preinst - Este script é executado antes que o pacote seja descompactado do seu arquivo Debian (".deb"). Muitos scripts 'preinst' interrompem os serviços para pacotes que estão sendo atualizados até que sua instalação ou atualização seja concluída (após a execução bem-sucedida do script 'postinst').

postinst - Esse script normalmente completa qualquer configuração necessária do pacote foo, uma vez que o foo foi descompactado do seu arquivo Debian (".deb"). Freqüentemente, os scripts 'postinst' solicitam entrada ao usuário e / ou avisam o usuário que, se ele aceitar valores padrão, ele deve se lembrar de voltar e reconfigurar esse pacote conforme a situação o justifique. Muitos scripts 'postinst' executam todos os comandos necessários para iniciar ou reiniciar um serviço após a instalação ou atualização de um novo pacote.

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

A sintaxe de chamar start | stop | restart é escrita como condicional, consulte https://www.debian.org/doc/debian-policy/ch-opersys.html seção 9.3.3.2 Executando initscripts

se qual invocar-rc.d> / dev / null 2> & 1; então

pacote invoke-rc.d

outro

/etc/init.d/package

fi

então ...

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

e adicione outra condicional para systemd quando necessário;)

Portanto, sim, a maneira correta de iniciar | parar | reiniciar um serviço é com o script de wrapper apropriado (invoke-rc.d / system), quando possível, em vez de chamar o script init (/etc/init.d/package) e retornando ao script /etc/init.d quando nenhum wrapper estiver disponível.

Uma maneira melhor para os sistemas systemd é usar deb-systemd-invoke .