Por que o systemd não está reiniciando este serviço que tem Restart = always?

3

Eu tenho um daemon de backup em execução no meu servidor que falha a cada poucos dias. Não sei porquê. A longo prazo, gostaria de descobrir o motivo e corrigi-lo, mas nesse meio tempo, gostaria que o systemd o reiniciasse quando falhasse.

Tem um script de init SysV de estilo antigo, que está sendo escolhido pelo systemd-sysv-generator. Aparentemente, quando ele trava, ele faz isso com um código de saída zero ("bem-sucedido"). Para tentar fazer com que ele seja reiniciado após essas falhas, deixei cair um override.conf :

~$ cat /etc/systemd/system/crashplan.service.d/override.conf
[Service]
Restart=always

systemd parece estar pegando isso:

roberts:~$ sudo systemctl show crashplan.service | grep Restart
Restart=always
RestartUSec=100ms

No entanto, quando eu verifiquei depois de alguns dias, encontrei:

roberts:~$ sudo systemctl status crashplan.service
● crashplan.service - LSB: CrashPlan Engine
   Loaded: loaded (/etc/init.d/crashplan; bad; vendor preset: enabled)
  Drop-In: /etc/systemd/system/crashplan.service.d
           └─override.conf
   Active: active (exited) since Thu 2017-01-05 00:33:50 PST; 5 days ago
     Docs: man:systemd-sysv-generator(8)

Jan 05 00:33:50 roberts systemd[1]: Stopped LSB: CrashPlan Engine.
Jan 05 00:33:50 roberts systemd[1]: Starting LSB: CrashPlan Engine...
Jan 05 00:33:50 roberts crashplan[25491]: Starting CrashPlan Engine ... Using standard startup
Jan 05 00:33:50 roberts crashplan[25491]: OK
Jan 05 00:33:50 roberts systemd[1]: Started LSB: CrashPlan Engine.

Então ... systemd parece pensar que não está funcionando e isso é legal? Não há registros sugerindo que ele até tentou reiniciá-lo? Eu não consigo nem descobrir como saber quando ele caiu. O que está acontecendo aqui?

    
por Nathaniel J. Smith 10.01.2017 / 12:49

1 resposta

3

Quando o script init.d não especifica um arquivo PID , sua unidade autogerada possui RemainAfterExit=yes . Na maioria dos casos, esses scripts representam tarefas comuns que não têm um processo de execução longa, portanto, essa opção faz com que essas unidades apareçam como 'ativas' mesmo depois que o processo é encerrado.

Isso permite que o administrador "pare" uma unidade manualmente (por exemplo, "iniciar" /etc/init.d/iptables carregar regras de firewall e "parar" que as liberaria). No entanto, como a unidade está sempre 'ativa', significa que a lógica de reinicialização nunca será acionada. (Afinal de contas, não há nada para reiniciar.)

A solução aqui seria escrever um arquivo .service systemd nativo para o CrashPlan - ou pelo menos fazer o daemon produzir um pidfile e adicionar # pidfile: /run/... ao initscript de acordo.

... Como alternativa, execute primeiro systemctl cat crashplan.service para ver o conteúdo completo da unidade e, em seguida, desfaça manualmente todos os parâmetros errados: RemainAfterExit, GuessMainPID e assim por diante.

Veja também o commit f87883039 e o arquivo sysv-generator.c linha 197 .

    
por 10.01.2017 / 14:50

Tags