Um script de inicialização sempre retorna um código de saída adequado ao executar o status?

Question

Estou tentando escrever um script de tarefa cron que verificará se meus serviços estão em execução e os reiniciará, se não estiverem, portanto, não preciso fazer isso manualmente.

Agora, consultei on-line como verificar o status de um serviço em um script bash e encontrei basicamente o seguinte, com algumas variações:

ps auxw | grep <service_name> | grep -v grep

if [[ $? != 0 ]]; then
        /etc/init.d/<service_name> start
fi

Eu pensei um pouco e achei que seria um pouco menos hacky e mais uma maneira de usar a funcionalidade geral do script de inicialização para verificar da seguinte maneira:

/etc/init.d/<service_name> status

if [[ $? != 0 ]]; then
    /etc/init.d/<service_name> start
fi

Por favor, corrija-me se estiver errado, mas isso não funcionaria sempre? Esta é uma propriedade dos scripts init em geral, que eles retornam esse código de saída? Desde já, obrigado. :)

    

Answer 1

Não é 100% do tempo. No entanto, é um bom critério.

O CFEngine 3 usa isso em "promessas de serviços" para verificar se os serviços estão sendo executados. Se o código de saída de /etc/init.d/<servicename> status for zero, ele pressupõe que o serviço está sendo executado.

Acabei de encontrar o descumprimento do BitBucket com esta convenção: /etc/init.d/atlbitbucket status retorna 0 mesmo quando não está em execução. No entanto, eu consideraria isso um comportamento indesejável (um bug) no script de inicialização, que não segue a convenção.

Encontrou uma referência para isso; a Especificação da base padrão do Linux declara:

If the status action is requested, the init script will return the following exit status codes.

0         program is running or service is OK
1         program is dead and /var/run pid file exists
2         program is dead and /var/lock lock file exists
3         program is not running
4         program or service status is unknown
5-99      reserved for future LSB use
100-149   reserved for distribution use
150-199   reserved for application use
200-254   reserved

Então, sim, aplicativos compatíveis podem ser considerados para se comportarem dessa maneira.