Executando um script durante a inicialização / inicialização; init.d vs cron @reboot

Question

No momento, estou tentando entender a diferença entre init.d e cron @reboot para executar um script na inicialização / inicialização do sistema.

O uso de @reboot (este método foi mencionado em este fórum por hs.chandra ) é mais simples, basta acessar crontab -e e criar um @reboot /some_directory/to_your/script/your_script.txt e, em seguida, your_script.txt será executado toda vez que o sistema for reinicializado. Uma explicação detalhada de @reboot é aqui

Como alternativa, incorpore /etc/init.d/your_script.txt na segunda linha do seu script, por exemplo:

#!/bin/bash
# /etc/init.d/your_script.txt

Você pode executar chmod +x /etc/init.d/your_script.txt e isso também deve resultar para que your_script.txt seja executado toda vez que o sistema for inicializado.

Q1: Quais são as principais diferenças entre os dois?
Q2: Qual é mais robusto?
Q3: Existe um melhor entre os dois?
Q4: Esta é a maneira correta de incorporar um script para ser executado durante a inicialização?

Eu estarei incorporando um arquivo .sh bash para ser executado durante a inicialização.

    

Answer 1

init.d , também conhecido como script SysV, destina-se a iniciar e interromper serviços durante a inicialização e o encerramento do sistema. ( /etc/init.d/ scripts também são executados em sistemas ativados pelo systemd para compatibilidade).

• O script é executado durante a inicialização e o encerramento (por padrão).
• O script deve ser um script init.d, não apenas um script. Deve suportar start e stop e mais (consulte política Debian )
• O script pode ser executado durante a inicialização do sistema (você pode definir quando).

crontab (e, portanto, @reboot ).

• o cron executará qualquer comando ou script regular, nada de especial aqui.
• qualquer usuário pode adicionar um script @reboot (não apenas root)
• em um sistema Debian com o systemd: o @reboot do cron é executado durante multi-user.target .
• em um sistema Debian com SysV (não systemd), mencione crontab (5): Por favor, note que startup, no que diz respeito a @reboot, é a hora em que a inicialização do daemon cron (8). Em particular, pode ser antes que alguns daemons do sistema, ou outras instalações, sejam iniciados. Isso se deve à sequência de ordem de inicialização da máquina.
• é fácil agendar o mesmo script na inicialização e periodicamente.

/etc/rc.local é considerado frequentemente feio ou obsoleto (pelo menos por redhat ), ainda tinha alguns recursos interessantes:

• O rc.local executará qualquer comando ou script regular, nada especial aqui.
• em um sistema Debian com SysV (não systemd): rc.local foi (quase) o último serviço a ser iniciado.
• mas em um sistema Debian com systemd: rc.local é executado após network.target por padrão (não network-online.target !)

Em relação ao network.target e network-online.target do systemd, leia Serviços em execução após a conclusão da rede .

    

Answer 2

Em primeiro lugar, um esclarecimento está em ordem:

• init.d é o diretório que armazena os scripts de controle de serviços, que controlam o início e a interrupção de serviços, como httpd ou cron
• rc.local é um serviço que permite a execução de scripts arbitrários como parte do processo de inicialização do sistema

Em termos de saber se é melhor usar rc.local ou cron para executar seu script, suspeito que seja mais uma questão de estética do que de praticidade. cron , como agendador de tarefas, é um método para realizar manutenção ou manutenção em uma máquina, como verificar atualizações, limpar caches ou executar auditorias de segurança. Isso não significa que esteja limitado a executar essas funções, pois pode executar qualquer script ou comando desejado no horário especificado (como @reboot ).

Usar rc.local , por outro lado, cairia mais dentro de um tipo de tarefa de configuração do sistema, já que rc.local , sendo executado pelo sistema init das máquinas, é normalmente responsável por definir a configuração, os serviços ou os ambientes de rede das máquinas. (mas, novamente, não se limita a apenas esta tarefa).

Ambos os pontos, no entanto, devem ser temperados pelo fato de que nem todos os sistemas init oferecem um mecanismo rc.local , e nem todos os daemons do cron oferecem uma tag @reboot psuedo.

Pontos de bônus

Como mencionado, init.d é o diretório que contém os scripts que controlam serviços que podem ser iniciados ou parados em seu sistema (pelo menos em máquinas que usam um sistema init SysV type). Dependendo do seu sistema init e do propósito do seu script, pode ser razoável converter seu script em um script de inicialização para ser executado da mesma maneira que um serviço. Isso, no entanto, é altamente dependente de seu sistema init, já que a estrutura que envolve esses arquivos é muito diferente.

Última palavra

Também deve ser notado que tipicamente os scripts bash terminam com um sufixo de .sh em vez de .txt , pois isso imediatamente denota que o arquivo é um script de shell em vez de um arquivo de texto. Dito isto, desde que tenha um shebang ( #!/bin/bash ) no topo do arquivo, ou seja chamado como bash /path/to/script.whatever , não deveria importar em termos de execução do script. / p>     

Answer 3

Estou escrevendo minha resposta abaixo;

Q1: What is the key differences between the two?

Além das diferenças mencionadas por outros usuários acima, eu gostaria de destacar o ponto que @reboot é dependente do daemon do crond. Você depende da ordem em que o crond começa. Embora a maioria dos casos, crond começa bem, mas pode falhar em algum momento para iniciar (pelo menos eu vi algumas falhas em alguns dos meus projetos). Quando você escreve um script de inicialização, a falha normalmente ocorre se você fizer algo errado no seu script (ex: confiar em um serviço que será iniciado após o seu serviço)

Q2: Which is more robust?

Com base no acima, acho que o init é mais robusto. Mas há outro ponto mencionado por "Franklin Piat" na primeira resposta. Normalmente você precisa de um script de inicialização para um daemon e deve seguir a política

Q3: Is there a better one out of the two?

Eu não penso assim (rc.local é um pouco velho e obsoleto)

Q4: Is this the correct way of embedding a script to run during booting?

Sim. Geralmente os editores de aplicativos / pacotes fazem isso.