Quando è necessario un riavvio?


27

Oltre all'aggiornamento del kernel, ci sono cambiamenti in un sistema Linux che richiedono un riavvio? So che ci sono situazioni in cui un riavvio rende le cose più facili, ma ci sono alcune che non possono essere realizzate se non con un riavvio?

Per chiarire: sto pensando a un tipico sistema desktop o server che non soffre di un malfunzionamento dell'hardware.


3
ogni cosa può essere fatta senza riavviare. anche cambiare il kernel può essere fatto usando ksplice in modo da poter sostituire a caldo il kernel. L'unica cosa che devi prendere in considerazione è il fatto che rendere tutto senza riavvio può essere molto complesso
Kiwy

4
La tua domanda è molto ampia, perché "sistema Linux" può significare molte cose molto diverse.
Zrin,

Anche "eventuali modifiche" può significare molte situazioni diverse. Il ripristino da un disco rigido guasto che fa parte di un mirror MD è una tale modifica? Se sì, allora - purtroppo - a volte richiederà un riavvio, perché ad esempio alcuni guasti dell'HDD (su alcuni controller HDD) sono in grado di non rispondere al sistema. Ma probabilmente non ti stai chiedendo di tali "cambiamenti" ...
Zrin

3
@Kiwy Tecnicamente ksplice non cambia il kernel . Ksplice permette a un kernel in esecuzione di essere patchato, mentre è in esecuzione. Potresti pensare a kexec , che consente di caricare una nuova immagine del kernel "su" un kernel in esecuzione in memoria.
Thomas Nyman,

Questo mi ricorda, Windows XP (non sono mai andato oltre) non si interrompe mai sul riavvio anche se ha appena aggiornato IE8 (o qualsiasi numero) che non è stato aperto per 4 anni, dall'installazione di Windows e quindi la necessità di scaricare un browser.
Shahbaz,

Risposte:


44

Mi vengono in mente un paio di cose:

  • Recupera dal panico del kernel

    Un panico del kernel, per definizione, non può essere recuperato senza riavviare il kernel.

  • Recupera da 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, ti consigliamo di evitare il ciclo di accensione manuale. 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é l' CONFIG_MAGIC_SYSRQopzione è stata abilitata nella configurazione del kernel e l' kernel.sysrq sysctlopzione è abilitata, è possibile inviare comandi direttamente al kernel con combinazioni di tasti magici SysRq:

    Si noti che Alt+ SysRqsotto indica di tenere premuto Alt , quindi tenere premuto SysRq (in genere il PrintScrntasto).

    1. Alt+ SysRq+ r: riprende il controllo della tastiera
    2. Alt+ SysRq+ e: invia SIGTERMa tutti i processi, tranne init, dando loro la possibilità di terminare con grazia
    3. Alt+ SysRq+ i: invia SIGKILLa tutti i processi, eccetto init, costringendoli a terminare
    4. Alt+ SysRq+ s: tenta di sincronizzare tutti i filesystem montati
    5. Alt+ SysRq+ u: rimonta tutto il filesystem in sola lettura
    6. Alt+ SysRq+ b: riavvia o

      Alt+ SysRq+ o: spegnimento

    Un mnemonico per le magiche combinazioni di tasti SysRq per tentare un riavvio grazioso è:

    " R eboot E ven I f S istema U tterly B roke "

    Per i server senza testa, esiste persino un target iptables che consente sequenze SysRq remote su una rete.

  • Ripristina dallo stato non avviabile

    Se il sistema è già stato portato in uno stato in cui non è possibile un avvio regolare (ad es. A causa di un aggiornamento del sistema fallito, un filesystem corrotto ecc.), L'unico modo per accedere a una console di ripristino sul sistema potrebbe essere il riavvio utilizzando le opzioni di avvio appropriate.

  • Modifica i parametri del kernel all'avvio

    Alcuni parametri del kernel (ad esempio auditper abilitare / disabilitare il controllo del kernel) possono essere impostati solo quando il kernel è caricato all'avvio.


3
"Riavvia anche se il sistema si è completamente rotto" Preferisco questa domanda per ogni evenienza, ma non credo che lo dimenticherò mai.
embedded.kyle

1
Vale forse la pena notare che puoi uscire dal panico usando un kexec ed evitare un riavvio completo. Questo vale anche per uscire dal punto di stato non avviabile. (non sono la stessa cosa in alcun modo, almeno su un sistema x86). Tuttavia +1 per il resto di questa risposta.
Valità

@Valità Grazie per il tuo commento. Se kexec comporta un riavvio dipende forse in una certa misura dal proprio punto di vista. La documentazione di kdump, ad esempio, descrive kexec-on-panic come un riavvio che preserva l'immagine di memoria del kernel di sistema. Per quanto riguarda il punto sullo stato non avviabile, ho anche considerato cose come la configurazione errata del bootloader (ad esempio il mancato caricamento del kernel in primo luogo), dove kexec non aiuta. Data la natura della domanda, penso che sia inevitabile una certa differenza di opinione sulla semantica.
Thomas Nyman,

@ThomasNyman Grazie per la tua risposta dettagliata, vedo la domanda che hai ragione. Penso che parlare di Kexec probabilmente complicherà inutilmente le cose per il pubblico target o questa domanda. E fai anche un buon punto per quanto riguarda gli errori del boot loader.
Valità

Non avevo mai notato quel piccolo SysRq scritto sotto lo schermo di stampa! Questo e spettacolare. Vorrei averlo saputo quando stavo imparando la programmazione del modulo del kernel!
Shahbaz,

2

Ci sono due volte che riesco a pensare a dove vorrei riavviare:

  1. 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 ha provocato 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 è stato spento per giorni mentre abbiamo capito come riconfigurarlo.

    Il riavvio effettivo è l'unico modo per sapere con certezza che il sistema si riavvierà correttamente dopo un'interruzione di corrente.

  2. Quando una libreria di sistema è stata aggiornata.

    Diciamo che è stato scoperto un grave difetto di sicurezza in una libreria condivisa con molte app / server sul sistema. È possibile aggiornare la libreria senza riavviare, ma quanti processi sono ancora in esecuzione con la libreria non protetta caricata? Puoi riavviare scrupolosamente qualsiasi cosa usando 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.


Esistono modi migliori per trovare tutti i file binari in base a una determinata libreria se si utilizza un buon gestore di pacchetti. mi viene in mente il revdep-ricostruito da Gentoo.
Spidey,

1
@Spidey: una volta ricostruiti quei file binari, come assicurarti che non ci siano vecchi processi in esecuzione con la libreria buggy?
Gabe,

1
Come fai a sapere quali demoni hanno caricato le librerie offensive?
Gabe,

1
@Gabe Ad esempio, è possibile verificare quali processi hanno le librerie mappate sul loro spazio di memoria utilizzando lsofprima di aggiornare le librerie.
Thomas Nyman,

1
@Gabe Certo, e mentre sono d'accordo che questo è un buon motivo per il riavvio, il PO è esplicitamente non chiede in quali casi un riavvio è più conventient, ma quando un riavvio è assolutamente necessario .
Thomas Nyman,

0

Se intendi cambiamenti pianificati nella configurazione del software e presumi un hardware perfettamente funzionante (non l'ho ancora visto) e un software privo di bug (sai ...), allora solo un bug nel kernel o un driver ti costringerebbe a riavvio. :)

A parte questo ... Non sono sicuro che sarebbe possibile sostituire initsenza passare alla modalità utente singolo e fare un po 'di magia che in sostanza non è molto diversa da un riavvio.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.