Atualmente, estou tentando entender a diferença entre init.de cron @rebootpara executar um script na inicialização / inicialização do sistema.

O uso de @reboot(este método foi mencionado neste fórum por hs.chandra ) é um pouco mais simples, basta entrar crontab -ee criar um @reboot /some_directory/to_your/script/your_script.txte your_script.txtdeve ser executado sempre que o sistema for reiniciado. Uma explicação detalhada de @rebootestá aqui

Como alternativa, incorporando /etc/init.d/your_script.txta segunda linha do seu script, ou seja:

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

Você pode executar chmod +x /etc/init.d/your_script.txte isso também deve resultar em your_script.txtexecução sempre que o sistema for inicializado.

Q1: Quais são as principais diferenças entre os dois?
P2: Qual é mais robusto?
Q3: existe um melhor dos dois?
P4: Essa é a maneira correta de incorporar um script para executar durante a inicialização?

Estarei incorporando um arquivo .sh do bash para executar durante a inicialização.

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

• O script é executado durante a inicialização e o desligamento (por padrão).
• O script deve ser um script init.d, não apenas um script. Deveria suportar starte stopmais (veja a 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 @rebootscript (não apenas root)
• em um sistema Debian com systemd: o @reboot do cron é executado durante multi-user.target.
• em um sistema Debian com SysV (não systemd), o crontab (5) menciona: Observe que a inicialização, no que diz respeito ao @reboot, é a hora em que o daemon cron (8) é iniciado. Em particular, pode ser antes de alguns daemons do sistema ou outras instalações serem iniciados. Isso ocorre devido à sequência de ordem de inicialização da máquina.
• é fácil agendar o mesmo script na inicialização e periodicamente.

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

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

Em relação ao systemd network.targete network-online.target, leia Serviços em execução depois que a rede estiver ativa .

Em primeiro lugar, há um esclarecimento:

• init.d é o diretório que armazena scripts de controle de serviços, que controlam o início e a parada de serviços como httpdoucron
• 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 se é melhor usar rc.localou cronexecutar o seu script, suspeito que seja mais uma questão de estética do que de praticidade. cron, como planejador de tarefas, destina-se a um método para executar 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 está limitado a executar essas funções, pois ele pode executar qualquer script ou comando desejado no horário especificado (como @reboot).

Utilizando rc.local, por outro lado, iria cair mais dentro de um tipo de configuração do sistema de tarefa, como rc.local, a ser executado pelas máquinas sistema de inicialização, é tipicamente responsável por definir a configuração de rede de máquinas, serviços ou ambientes (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 rc.localmecanismo, e nem todos os daemons cron oferecem um @reboottag psuedo.

Pontos bônus

Como mencionado, init.dé o diretório que contém os scripts que controlam os serviços que podem ser iniciados ou parados no seu sistema (pelo menos em máquinas que usam um SysVsistema init do tipo). Dependendo do seu sistema init e da finalidade do seu script, pode ser razoável converter seu script em um script init para ser executado da mesma maneira que um serviço. Isso, no entanto, depende muito do seu sistema init, pois a estrutura em torno de como esses arquivos são construídos pode diferir bastante.

Última palavra

Também deve-se notar que os scripts bash geralmente terminam com um sufixo em .shvez de .txt, pois isso indica imediatamente que o arquivo é um script de shell em vez de um arquivo de texto. Dito isto, desde que ele tenha um shebang ( #!/bin/bash) na parte superior do arquivo ou seja chamado como bash /path/to/script.whatever, não deve importar em termos de execução do script.

Estou escrevendo minha resposta abaixo;

Q1: Quais são as principais diferenças entre os dois?

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

P2: Qual é mais robusto?

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

Q3: existe um melhor dos dois?

Eu acho que não (o rc.local é um pouco antigo e obsoleto)

P4: Essa é a maneira correta de incorporar um script para executar durante a inicialização?

Sim. Geralmente, os criadores de aplicativos / pacotes fazem dessa maneira.