Attualmente sto cercando di capire la differenza tra init.de cron @rebootper l'esecuzione di uno script all'avvio / avvio del sistema.

L'uso di @reboot(questo metodo è stato menzionato in questo forum da hs.chandra ) è un po 'più semplice, semplicemente entrando crontab -ee creando un @reboot /some_directory/to_your/script/your_script.txte quindi your_script.txtdeve essere eseguito ogni volta che il sistema viene riavviato. Una spiegazione approfondita di @rebootè qui

In alternativa, incorporando /etc/init.d/your_script.txtnella seconda riga del tuo script, ovvero:

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

È possibile eseguire chmod +x /etc/init.d/your_script.txte ciò dovrebbe anche comportare your_script.txtl'esecuzione ogni volta che si avvia il sistema.

Q1: quali sono le differenze chiave tra i due?
Q2: qual è più robusto?
Q3: ce n'è uno migliore dei due?
Q4: è questo il modo corretto di incorporare uno script da eseguire durante l'avvio?

Incorporerò un file .sh bash da eseguire durante l'avvio.

init.d, noto anche come script SysV, è pensato per avviare e arrestare i servizi durante l'inizializzazione e l'arresto del sistema. (gli /etc/init.d/script vengono eseguiti anche su sistemi abilitati per systemd per compatibilità).

• Lo script viene eseguito durante l'avvio e l'arresto (per impostazione predefinita).
• Lo script dovrebbe essere uno script init.d, non solo uno script. Dovrebbe supportare starte stopaltro (vedi la politica Debian )
• Lo script può essere eseguito durante l'avvio del sistema (è possibile definire quando).

crontab(e quindi @reboot).

• cron eseguirà qualsiasi comando o script regolare, niente di speciale qui.
• qualsiasi utente può aggiungere uno @rebootscript (non solo root)
• su un sistema Debian con systemd: cron's @reboot viene eseguito durante multi-user.target.
• su un sistema Debian con SysV (non systemd), menzione crontab (5): Si noti che l'avvio, per quanto riguarda @reboot, è il momento in cui l'avvio del demone cron (8). In particolare, potrebbe essere prima dell'avvio di alcuni daemon di sistema o di altre strutture. Ciò è dovuto alla sequenza dell'ordine di avvio della macchina.
• è facile programmare lo stesso script all'avvio e periodicamente.

/etc/rc.localè spesso considerato brutto o deprecato (almeno da redhat ), tuttavia aveva alcune belle caratteristiche:

• rc.local eseguirà qualsiasi comando o script regolare, niente di speciale qui.
• su un sistema Debian con SysV (non systemd): è rc.localstato (quasi) l'ultimo servizio ad avviarsi.
• ma su un sistema Debian con systemd: rc.localviene eseguito dopo network.targetdi default (no network-online.target!)

Per quanto riguarda systemd network.targete network-online.target, leggere Running Services dopo che la rete è attiva .

Innanzitutto, è necessario un chiarimento:

• init.d è la directory che memorizza gli script di controllo dei servizi, che controllano l'avvio e l'arresto di servizi come httpdocron
• rc.local è un servizio che consente l'esecuzione di script arbitrari come parte del processo di avvio del sistema

Per quanto riguarda se è meglio usare rc.localo croneseguire la tua sceneggiatura, sospetto che sia più una questione di estetica che di praticità. cron, come programmatore di attività, è inteso come un metodo per eseguire la manutenzione o la manutenzione di una macchina, come il controllo degli aggiornamenti, la pulizia delle cache o l'esecuzione di audit di sicurezza. Ciò non significa che sia limitato all'esecuzione di tali funzioni, in quanto può eseguire qualsiasi script o comando desiderato al momento specificato (come @reboot).

L'uso rc.local, d'altra parte, rientrerebbe maggiormente in un tipo di attività di configurazione del sistema, poiché rc.local, essendo eseguito dal sistema init machine, è in genere responsabile dell'impostazione della configurazione della rete, dei servizi o degli ambienti delle macchine (ma, di nuovo, non si limita solo a questo compito).

Entrambi questi punti, tuttavia, dovrebbero essere mitigati dal fatto che non tutti i sistemi init offrono un rc.localmeccanismo, e non tutti i demoni cron offrono un @reboottag psuedo.

Punti bonus

Come accennato, init.dè la directory che contiene gli script che controllano i servizi che possono essere avviati o arrestati sul sistema (almeno sui computer che utilizzano un SysVsistema di tipo init). A seconda del sistema init e dello scopo dello script, può essere ragionevole convertire lo script in uno script init da eseguire allo stesso modo di un servizio. Ciò, tuttavia, dipende fortemente dal sistema init in quanto il framework che circonda il modo in cui sono costruiti questi file può differire notevolmente.

Ultima parola

Va inoltre notato che in genere gli script bash terminano con un suffisso .shanziché anziché .txt, poiché ciò indica immediatamente che il file è uno script shell anziché un file di testo. Detto questo, purché abbia uno shebang ( #!/bin/bash) nella parte superiore del file, o sia chiamato come bash /path/to/script.whatever, non dovrebbe importare in termini di esecuzione dello script.

Sto scrivendo la mia risposta di seguito;

Q1: quali sono le differenze chiave tra i due?

A parte le differenze menzionate da altri utenti sopra, vorrei sottolineare il fatto che @reboot dipende dal demone crond. Sei dipendente dall'ordine in cui inizia la cronda. Anche se la maggior parte dei casi, crond inizia bene, ma potrebbe non riuscire a iniziare (almeno ho visto alcuni fallimenti in alcuni dei miei progetti). Quando si scrive uno script init, in genere si verificherebbe un errore se si fa qualcosa di sbagliato nello script (un esempio: fare affidamento su un servizio che inizierà dopo il servizio)

Q2: qual è più robusto?

Sulla base di quanto sopra, penso che init sia più robusto. Ma c'è un altro punto menzionato da "Franklin Piat" nella prima risposta. Di solito hai bisogno di script di init per un demone e dovresti seguire la politica

Q3: ce n'è uno migliore dei due?

Non credo (rc.local è un po 'vecchio e deprecato)

Q4: è questo il modo corretto di incorporare uno script da eseguire durante l'avvio?

Sì. Normalmente gli autori di pacchetti / applicazioni fanno in questo modo.