O status do systemctl deve refletir o status do serviço em todos os casos?

Question

Suponha que há um aplicativo app instalado no servidor e ele fornece um controle de aplicativo chamado appctl . Como administrador, posso iniciar / parar / reiniciar o aplicativo via appctl :

appctl start
appctl stop
appctl restart

Então, percebi que deveria usar systemctl para fazer isso, então escrevi um app.service e vinculei o arquivo de serviço a /etc/systemd/system . Depois de recarregar o daemon, posso iniciar / parar / reiniciar o aplicativo via systemctl :

systemctl start app.service
systemctl stop app.service
systemctl restart app.service

Agora, minha pergunta vem: Depois de parar meu aplicativo usando appctl restart , o status no sistema systemctl status app.service disse inativo (inativo) desde 1 hora atrás . Isso não reflete para o status real do aplicativo. É aceitável?

Pessoalmente, sinto que é normal, porque não usei systemctl para reiniciar. Mas eu gostaria de ter mais argumentos, como citações da documentação, análise do mecanismo interno systemctl .

    

Answer 1

Você está certo de que este é o resultado esperado. Eu não esperaria que appctl impedisse que isso acontecesse como tal. No entanto, pode valer a pena pensar em como você pode incentivar o uso correto.

O administrador do sistema provavelmente precisa ser informado de que não deve usar diretamente o appctl start/restart . Não é apenas que o estado do serviço "não reflete o status real do aplicativo". Você ignorou o systemd, perdendo quaisquer vantagens, por exemplo o daemon herdará vários atributos de qualquer shell do qual você executou appctl start . E systemctl stop app.service não funcionará :). Também qualquer tratamento de encerramento personalizado, e. ExecStop= não será executado no desligamento do sistema.

Os próprios programas daemon do systemd encorajam isso ao serem instalados sob um subdiretório / usr / lib em vez de / usr / bin ou / usr / sbin. systemd-udevd , por exemplo, não está no PATH do usuário. / usr / libexec / (subdiretório ou não) está disponível para a mesma coisa. Tecnicamente, você pode fazer a mesma coisa mesmo ao fornecer um estilo de script do sistema V ...

No entanto, existem argumentos para o acesso conveniente aos programas daemon, por ex. quando você tem uma configuração complexa e quer receber mensagens de erro no terminal. Um exemplo disso seria apache -t .

Se você tiver verbos diferentes de reload (um serviço systemd também pode definir ExecReload) e iniciar / reiniciar / parar, convém mantê-los separados. Por exemplo. use o daemon principal binário para implementar esses quatro e coloque qualquer outra coisa em appctl . Por exemplo. O reinício gracioso do Apache viria nesta categoria.

Os administradores do sistema "devem" já entender que iniciar o appd diretamente tem desvantagens significativas, mesmo se estiver em seu PATH, mas que appctl é bom para executar a partir do terminal.