Executando o script init que inicia um daemon em segundo plano para reduzir o tempo de inicialização?

Question

Estou procurando maneiras de acelerar o tempo de inicialização em um sistema Linux integrado de núcleo único. Um atraso significativo ocorre durante o início de alguns daemons personalizados. Uma vez que estão funcionando, eles são executados em segundo plano, mas o processo de execução é demorado demais.

##This takes long during startup
##In file /etc/init.d/run_custom_daemon
...
/opt/bin/custom_daemon -d
...

Eu experimentei uma diminuição no tempo de inicialização se eu colocasse o início dos daemons em segundo plano.

##This takes much less but is it a real gain?
##In file /etc/init.d/run_custom_daemon
...
/opt/bin/custom_daemon -d &
...

Do ponto de vista de alguém apenas olhando quanto tempo leva para chegar à tela de login, isso pode parecer uma aceleração. No entanto, acho que isso pode ser apenas um ganho estético que pode levar a problemas se o próximo processo na sequência de inicialização esperasse que o daemon estivesse sendo executado no ponto em que está sendo iniciado.

Esta é uma suposição correta?

    

Answer 1

Normalmente daemons garfo duplo ou triplo e os pais saem. Quando um daemon é iniciado em bg, o shell não interativo não espera que o primeiro fork saia. E porque não tem nada para fazer, sai imediatamente. Isso pode acelerar um pouco. Eu não penso em nenhuma conseqüência ruim disso se você tiver certeza de que o daemon não falhará.

Para acabar com um fork e, consequentemente, acelerar, ele pode ser 'exec'd como exec daemon . Mas 'bg' e 'exec' não podem obter o valor de retorno do daemon.

No momento em que 'init' ou algum agente gerado pelo init foi descoberto por alguma mágica de shell, o próximo script de inicialização para executar e clonar-se para exec 'o próximo init scritp' e a família de funções exec [lv] * encontrou #! e executar o interpretador com 'o próximo script de inicialização' como seus argumentos e o interpretador analisou e executou 'o próximo script de inicialização' até iniciar o próximo daemon com kernel agarrando tempo de CPU intermitentemente ..., o primeiro daemon teria iniciado .

A primeira bifurcação de algum daemon não tem nada a ver exceto verificar a saída do segundo syscall 'fork' e sair. Outros podem fechar abrir 'fd's e abrir / dev / null em 0,1 e 2 no primeiro fork do que no adiamento. Alguns benchmarking podem revelar desempenho.