Qual é o tempo máximo de inicialização permitido para um script de inicialização do daemon?
Eu tenho um servidor tomcat que leva muito tempo para iniciar e eu poderia incluir lógica dentro do script de inicialização para verificar se o serviço foi iniciado com êxito ou não.
Ainda assim, tenho algumas preocupações em relação a um possível loop infinito para a inicialização do daemon, o que pode impactar até mesmo a inicialização do sistema se isso estiver configurado para ser executado no momento da inicialização.Ainda assim, desejo retornar uma mensagem de saída adequada (sucesso / falha).
Eu poderia implementar uma lógica de timeout, mas não tenho ideia do que seria considerado um tempo de inicialização aceitável ou inaceitável para um script de daemon.
Além disso, não faz muito sentido parar a inicialização de outros serviços enquanto este serviço ainda está sendo inicializado.
Não há "tempo máximo de inicialização permitido" para um script de inicialização do sistema. No entanto, para scripts de longa execução, o que acontece é que o script de inicialização geralmente desmembrará o programa que leva muito tempo como um processo em segundo plano ou até mesmo um processo "at". Assim, isso evita que um processo de execução lenta demore muito antes que o sistema esteja "pronto" para ser executado.
Como já foi dito, não há tempo de inicialização máximo ou configurável para um daemon. Se você acha que o daemon está fazendo com que outros daemons sejam iniciados, você pode alterar sua sequência de inicialização no final.
Para depurar o problema, posso pensar em três maneiras agora.
1) A etapa óbvia seria habilitar logs de depuração para o aplicativo. Eu principalmente trabalho com RHEL e /etc/sysconfig/<daemon-name> é onde o nível de log pode ser definido.
2) Quando você inicia manualmente o daemon, inicie-o com strace.
strace -ffttTo /tmp/daemon.out /etc/init.d/daemon start
Agora, no arquivo daemon.out, observe a hora impressa no final de cada syscall. Isso é em microssegundos. Descobrir a chamada que consome a maior parte do tempo.
Quando você descobrir isso, inicie novamente o daemon e desta vez com o ltrace. Agora que você conhece o syscall ofensivo, descubra em qual biblioteca ele está ficando preso.
3) Escreva um script de systemtap. Este não é tão fácil a menos que o usuário tenha alguma experiência em escrever / depurar com stap.
probe syscall.*
{
( (pid) == target() )
printf("%s\n",name)
}
Isto mostrará todos os syscalls que o pid alvo irá lançar.
NOTA - Não vá para stap em primeiro lugar. Eu mencionei isso porque é uma ferramenta de depuração incrível para o kernel e eu não vi referência dele no site (ou talvez esquecido). Você precisa instalar os pacotes kernel-debuginfo, kernel-debuginfo-common, kernel-devel e systemtap. Em seguida, execute o script como
stap <script_name.stp> -x pid
Podemos ainda instrumentar o syscall em questão.