Fortunatamente questo problema non accade così frequentemente, almeno con una distribuzione e kernel stabilie, ma a volte il vostro amato Linux potrebbe andare in “Kernel Panic”.
Un kernel panic è un’azione intrapresa da un sistema operativo in caso di rilevamento di un errore fatale che non può recuperare in modo sicuro. Il termine è in gran parte specifico per sistemi Unix e Unix-like; per i sistemi operativi Microsoft Windows il termine equivalente è “errore di stop” (o, colloquialmente BSOD “Blue Screen of Death”).
Le routine del kernel che si occupano dell’opzione panico, nota come panic() nei derivati UNIX di AT&T e BSD Unix, sono generalmente progettati per emettere un messaggio d’errore su console, scaricare l’immagine della memoria del kernel su disco per una analisi post-mortem di debug e poi o attendere che il sistema sia riavviato manualmente, o effettuare un riavvio automatico.
L’impostazione predefinita è di aspettare, quindi se questo accade su uno dei vostri server e non ve ne accorgete tutti i suoi servizi potrebbro stare giù per qualche tempo, mentre con l’utilizzo di un riavvio automatico il problema potrebbe essere risolto rapidamente.
Possiamo configurare una direttiva per far si che quando capita un kernel panic il sistema automaticamente faccia reboot dopo X secondi.
Questa direttiva, che può essere inserita nelle righe del grub che fanno partire il sistema con i parametri preferiti, non fa altro che dire al kernel che, in caso si presenti un kernel panic, anzichè lasciare il pc bloccato per avvisare l’utente in qualche modo (come ad esempio facendo lampeggiare i led della tastiera), il sistema deve essere riavviato entro un tot di tempo.
Questa direttiva si inserisce nella riga in cui specifichiamo la root del sistema e si chiama:
“panic=XX” dove XX indica i secondi da aspettare prima di far ripartire il sistema, ad esempio panic=20.
I parametri di avvio, giusto per fare un esempio, potrebbero essere:
title=Gentoo Linux (2.6.31-gentoo-r6) RAID LVM2 root (hd0,4) kernel /boot/kernel-genkernel-x86_64-2.6.31-gentoo-r6 root=/dev/ram0 ramdisk=8192 real_root=/dev/md0 dolvm udev panic=20 vga=0x318 video=vesafb:mtrr,ywrap initrd /boot/initramfs-genkernel-x86_64-2.6.31-gentoo-r6
La riga che ci interessa è quella contrassegnata. E’ visibile il parametro panic=20.
In questo caso, abbiamo detto al kernel di riavviarsi dopo 20 secondi in caso di kernel-panic.
Tutto questo dev’essere, ovviamente, supportato dal rendere avviati al boot tutti i programmi/servizi che il nostro sistema deve avere a disposizione per eseguire determinati lavori che fanno parte dei suoi compiti.
Alternativa, usare sysctl
In alternativa alla opzione di boot si può mettere il parametro nel file /etc/sysctl.conf per includere il parametro kernel.panic come segue.
kernel.panic = 20
Dopo aver aggiunto questa opzione nel file sysctl utilizzare il comando:
sysctl -p /etc/sysctl.conf |
Per ri-leggere e abilitarlo (viene letto automaticamente nei prossimi riavvii).
SysRq key
Nei sistemi locali, è anche conveniente essere in grado di riavviare il sistema con la pressione dei tasti in caso di kernel panic. Invece di avere automaticamente un riavvio del sistema su un sistema locale, è possibile utilizzare i tasti magici SysRq per riavviare il sistema, se X si blocca o la tastiera viene ignorata.
Per abilitare SysRq aggiungere al file /etc/sysctl.conf l’opzione seguente:
kernel.sysrq = 1
E come sopra dare il comando:
sysctl -p /etc/sysctl.conf |
per abilitarlo nella sessione corrente.
Uso comune di SysRq
Un idioma comune per eseguire un riavvio in sicurezza di un computer Linux che è altrimenti bloccato è “Raising Elephants Is So Utterly Boring”, “Reboot Even If System Utterly Broken” o semplicemente ci si può ricordare la parola “BUSIER” da eseguire alla rovescia. Questo sta per:
unRaw (riprendi controllo della tastiera da X), tErminate (manda un SIGTERM a tutti i processi, permettendogli di terminare), kIll (manda un SIGKILL a tutti i processi, forzandoli a terminare immediatamente), Sync (sincronizza i dati su disco), Unmount (rimonta tutti i filesystem in modalità read-only), reBoot.
Questo può evitare che sia necessario un fsck al riavvio del sistema e da la possibilità ad alcuni programmi di salvare i backup di emergenza del lavoro non salvato.
In pratica, ogni comando può richiedere alcuni secondi per completarsi, soprattutto se il feedback non è disponibile sullo schermo a causa di un blocco o per problemi di visualizzazione. Per esempio, inviando il segnale SIGKILL ai processi che non hanno ancora finito può causare la perdita di dati.
Popular Posts:
- None Found
