inicia o serviço systemd no início do requisito

Question

Eu tenho um serviço que depende do mysql.service via Requires= . Isso é necessário, porque o serviço trava, se o mysql não estiver disponível.

A execução de systemctl restart mysql funciona bem. Ele interrompe meu serviço primeiro, reinicia o mysql e inicia meu serviço novamente.

Como posso configurar minha unidade, que também é iniciada novamente, se eu executar systemctl stop mysql && systemctl start mysql ?

Isso é especialmente um problema durante as atualizações autônomas do mysql do debian, porque o processo de atualização usa stop / start e não restart .

    

Answer 1

nova e melhor resposta

Claramente eu não tenho lido bem ontem. Parece que o seu problema pode ser facilmente resolvido adicionando mysql.service aos seus serviços WantedBy na seção [Install] .

depois de você reativar seu serviço, ele deve ser iniciado sempre que mysql.service for iniciado, desde que seu serviço esteja ativado

o resultado é assim:

[Unit]
Requires=mysql.service
After=mysql.service

[Install]
WantedBy=multi-user.target mysql.service

minha antiga resposta para referência:

Não sei se é possível configurar sua unidade para se comportar da maneira que você quer.

No entanto, resolvi problemas semelhantes instalando arquivos drop-in systemd para modificar a unidade estrangeira, no seu caso mysql.service .

supondo que sua unidade seja foo.service , você pode criar um arquivo .conf em /etc/systemd/system/mysql.service.d/ com o seguinte conteúdo:

[Unit]
Wants=foo.service
Before=foo.service

isso faria com que o systemd tentasse iniciar foo.service após cada início de mysql.service

pelo motivo de integralidade, e para citar a documentação :

In addition to /etc/systemd/system, the drop-in ".conf" files for system services can be placed in /usr/lib/systemd/system or /run/systemd/system directories. Drop-in files in /etc take precedence over those in /run which in turn take precedence over those in /usr/lib. Drop-in files under any of these directories take precedence over unit files wherever located. (Of course, since /run is temporary and /usr/lib is for vendors, it is unlikely drop-ins should be used in either of those places.)