Oggi mi è capitata una di quelle cose che è bello dire solo quando sono finite. Stavo sistemando una serie di nuovi virtual host sul webserver di un cliente quando, del tutto improvvisamente, la macchina ha smesso di rispondere a qualsiasi forma di comando. L’ambiente bash in cui stavo digitando i miei comandi sembrava integra, nel senso che mi era possibile effettuare qualsiasi normale operazione purché non avesse a che fare con il filesystem: funzionavano perfettamente comandi come top e ps, ma era impossibile effettuare il less di un file o addirittura ottenere il man di un qualsiasi comando… In tutti i casi ottenevo un brutale e inequivocabile Input/output error, sintomo tristemente evidente di un problema sul filesystem.
Non che sia una situazione in cui mi sono trovato spesso, grazie al cielo, ma trattandosi quasi sicuramente di un problema del controller RAID e non dei dischi (entrambi nuovi di zecca) ho deciso di effettuare un reboot, ma anche questo comando restituiva il medesimo errore: non essendo disponibile in memoria in forma di processo il kernel lo deve per forza prelevare dal filesystem, quindi… Input/output error.
Fatta questa romanzesca e noiosissima introduzione, vengo al sodo e registro qui il paio di comandi con cui sono riuscito a comunicare al kernel le mie cattive intenzioni:
# echo 1 > /proc/sys/kernel/sysrq
# echo b > /proc/sysrq-trigger
Con la prima istruzione ho abilitato il flag sysrq che permette di inviare comandi direttamente al kernel, mentre la seconda istruzione costituisce a tutti gli effetti il comando di reboot. Ecco alcuni link utili per conoscere meglio questa potentissima e preziosissima modalità di interazione con il kernel di Linux:
Tony Di Caprio
ma poi è partito?
Ivan Agliardi
Ueeeeeeeeeeeeee! Ciao Antò! 🙂 Yes, poi è partito e ora funziona tutto che è una meraviglia, anche se ho messo in conto al cliente un nuovo controller + due dischi 😉