Mi vengono in mente un paio di cose:
-
Ripristino da un kernel panic
Un kernel panic, per definizione, non può essere recuperato senza riavviare il kernel.
-
Ripristina dai blocchi che ti lasciano senza accesso al terminale
Se il sistema non risponde e sei bloccato senza un modo per inviare comandi per il ripristino, l'unica cosa che potresti essere in grado di fare è riavviare. Di solito, dovresti evitare il riavvio manuale dell'alimentazione. Per questo tipo di situazioni, il kernel Linux ha il supporto Magic SysRq che può essere utilizzato per riavviare la macchina in caso di emergenza.
Finché
CONFIG_MAGIC_SYSRQ
l'opzione è stata abilitata nella configurazione del kernel e ilkernel.sysrq
sysctl
l'opzione è abilitata, puoi inviare comandi direttamente al kernel con combinazioni magiche di tasti SysRq:Nota che Alt +SysRq sotto significa tenere premuto Alt , quindi tieni premuto SysRq (tipicamente PrintScrn chiave).
- Alt +SysRq +r :riprendere il controllo della tastiera
- Alt +SysRq +e :invia
SIGTERM
a tutti i processi, tranneinit
, dando loro la possibilità di terminare con grazia - Alt +SysRq +i :invia
SIGKILL
a tutti i processi, tranneinit
, costringendoli a terminare - Alt +SysRq +s :tenta di sincronizzare tutti i filesystem montati
- Alt +SysRq +u :rimonta tutto il filesystem in sola lettura
-
Alt +SysRq +b :riavviare o
Alt +SysRq +o :spegnimento
Un mnemonico per le magiche combinazioni di tasti SysRq per tentare un riavvio regolare è:
"R eboot E ven Io f S sistema U veramente B roccia "
Per i server headless, esiste persino un target iptables che abilita sequenze SysRq remote su una rete.
-
Ripristina da stato non avviabile
Se il sistema è già stato portato a uno stato in cui non è possibile un avvio regolare (ad es. a seguito di un aggiornamento del sistema non riuscito, file system corrotto ecc.), l'unico modo per accedere a una console di ripristino sul sistema potrebbe essere riavviare utilizzando le opzioni di avvio appropriate.
-
Modifica i parametri del kernel all'avvio
Alcuni parametri del kernel (ad esempio
audit
per abilitare / disabilitare il controllo del kernel) può essere impostato solo quando il kernel è caricato all'avvio.
Ci sono due volte in cui posso pensare a dove vorrei riavviare:
-
Quando devo assicurarmi che il sistema possa avviarsi nello stato corretto.
Una volta ho lavorato su un sistema che aveva un demone configurato mentre era in esecuzione. Dopo aver funzionato per alcuni anni, un'interruzione di corrente ne ha causato il riavvio, ma il demone non faceva parte del processo di avvio e nessuno aveva idea di come fosse stato configurato anni prima. Il sistema è rimasto inattivo per giorni mentre cercavamo di riconfigurarlo.
In realtà il riavvio è l'unico modo per sapere con certezza che il tuo sistema si riavvierà correttamente dopo un'interruzione di corrente.
-
Quando una libreria di sistema è stata aggiornata.
Supponiamo che sia stata scoperta una grave falla di sicurezza in una libreria condivisa con molte app/server sul sistema. Puoi aggiornare la libreria senza riavviare, ma quanti processi sono ancora in esecuzione con la libreria non sicura caricata? Puoi riavviare faticosamente qualsiasi cosa utilizzando la vecchia libreria (se riesci a capirlo), ma è soggetto a errori e può richiedere più tempo del semplice riavvio.
Il riavvio è il modo migliore per essere sicuri che tutti i processi in esecuzione non stiano ancora utilizzando la vecchia libreria difettosa.