Tenho vários serviços diferentes que podem ser reiniciados automaticamente (por exemplo, após uma atualização automática). Infelizmente, quando eles reiniciam, eles não aparecem. Eu posso dizer porque service <service name> status me diz que está inativo e não está listado com ps . Eu acredito que o systemd irá matar o serviço assim que o executável principal morrer. Os logs não mostram sinais de erros.
O serviço é definido como um serviço systemd, de Type=simple e sem PIDfile= . Eu gosto de manter assim, porque systemd 'possui' o processo (assim, conhece o PID) e eu não tenho que criar uma pasta gravável em /var/run/ primeiro.
Existe alguma maneira de dizer ao systemd para "varrer novamente" o processo recém-iniciado quando o processo inicial original morreu? Observe que o systemd não deve reiniciar o serviço, portanto, a maioria das opções relacionadas à reinicialização que encontrei no manual não se aplica.
SO: Ubuntu 15.04, systemd 219.
Não, não há. Essa é uma limitação rígida imposta pelo systemd e uma substancial mudança na expectativa de como os processos funcionam. Eu realmente espero que eu esteja errado aqui, e eu não encontrei ainda.
FWIW, você não está sozinho . As melhores sugestões até o momento são usar as unidades de tempo at , cron ou systemd. Eu entendo se isso é um pequeno consolo para você.
Is there any way to tell systemd to 'rescan' for another executable when the original executable died?
Executáveis não morrem. Processos morrem. Faça a pergunta certa e a resposta aparece. Existe uma maneira de informar ao sistema sobre um novo processo de serviço principal e transferi-lo para que o processo de serviço principal antigo possa sair silenciosamente? Sim existe. É o protocolo de notify de prontidão.
Eu nunca tentei eu mesmo, mas a maneira de fazer isso no modelo systemd é para o processo principal atual gerar o serviço de substituição executando a nova imagem do programa, então sd_notify systemd sobre o novo MAINPID , passar a tocha principal do processo para a nova e, em seguida, sair. (É um pouco mais complexo se o processo principal antigo tiver que negociar a entrega com o novo processo principal.)
Como eu disse, nunca usei isso, e não posso falar com nenhuma regressão nos anos intermediários, mas em 2011 é assim que as pessoas supostamente estavam resolvendo esse problema em particular.
(O outro design é, obviamente, não ter programas de serviço de auto-modificação, mas ter serviços de "atualização" separados que são executados fora do contexto de execução do serviço cujo programa está sendo atualizado.)