[TIP] Sobreviviendo a un kernel panic remoto.

No son leyenda urbana. Los kernel panics existen…

Mientras el hardware esté sano, linux no falla, pero ¿Y si el hardware falla? ¿Y si falla en un servidor al cual no tenemos acceso físico? En esos casos es vital que la pc o el servidor remoto reinicien automáticamente después de un kernel panic.

El kernel de linux por defecto no reinicia el sistema en caso de un kernel panic de forma de que sea accesible por pantalla el volcado de memoria y el error específico, y esto no siempre es lo que se necesita (sobre todo si el sistema remoto no tiene un monitor instalado o no hay nadie presente físicamente en el lugar).

Para lograr que el kernel reinicie el sistema en caso de un kernel panic hay que modificar el contenido del archivo /proc/sys/kernel/panic:

~ # echo 5 >> /proc/sys/kernel/panic

Donde 5 es la cantidad de segundos que queremos esperar antes de que se produzca el reinicio del sistema.

Verificando el contenido del archivo:

~ # cat /proc/sys/kernel/panic
5

De esta forma el cambio de aplica de manera inmediata, pero como el contenido del archivo panic es volatil, los cambios se pierden luego del primer reinicio del sistema operativo.

Para que el cambio sea efectivo de forma permanente hay que implementarlo sobre el archivo /etc/sysctl.conf descomentariando la siguiente línea:

# When the kernel panics, automatically reboot in 3 seconds
#kernel.panic = 3

O bien, pasarle el parametro en cuestión al kernel durante el arranque desde el boot loader, por ejemplo, agregando panic=5 a /boot/grub/menu.lst:

kernel /boot/kernel root /dev/sda1 panic=5

Usando la combinación de el parámetro panic con la opción fallback de grub  es posible por ejemplo, testear un nuevo kernel de manera remota, de esta forma, en caso de un kernel panic arrancando un nuevo kernel grub puede arrancar al segundo intento desde un kernel viejo, sistema de archivos viejo, etc, etc, pero eso es tema para otro artículo.

Mister Proper – El limpiador de azulejos y el kernel de Linux.

El señor Proper. Imagen de la marca de productos de limpieza.

Cuenta la leyenda urbana que el comando make mrproper que se usa para limpiar por completo la configuración del kernel de linux tiene ese nombre como alusión al producto de limpieza en cuestión. ¿Tan buen limpiador será?

¿Casualidad?

El kernel de Linux y Suspend / Resume

Para los que viven en el termo que ha sido dado en llamar «Microsoft WIndows» y no sabían nada de este asunto (que de todas formas dudo les importe un bledo), El kernel de linux ha tenido desde toda la vida problemas para supender y volver del modo suspendido, o hibernar y viceversa.

No es cosa de todos los días y no pasa con todo el hardware pero pasa. Es la causa por la cual nunca intenté siquiera usar alguna de estas funciones.

Buenas noticias malditos nerds:  Linus ayudado por un par de personas ha encontrado al fin entre los 300mb de puro texto sin comprimir el origen de la falla. Hoy es un día glorioso que quedará grabado para siempre en los anales de la historia de Linux!

Acabo de leer en el Blog de Linus la buena nueva:

Life is good again..
…because it looks like we figured out what the suspend/resume problem was. And as suspected, the actual resource code had nothing what-so-ever to do with it, and was apparently just a trigger for timing.

It’s frustrating with bugs like that, but on the other hand it’s then a big relief when it gets resolved, and in this case we also ended up going through a lot of code and I think we’ll be much better off as a result. It’s also a huge relief to find the actual root cause, rather than seeing things that can be used to paper over and hide the problem.

And kudos to the people who actually saw the problem (Rafael and Frans), and who spent a lot of time trying out different things and sending out logs and looking at the resource allocation. The real clue was in a log from a successful suspend/resume cycle that showed some questionable behaviour despite not actually failing.

Un poco mas adelante, en los comentarios, se le pregunta a Linus en cuanto tiempo estará disponible al público en general a lo que Linus responde:

LimbClock: it’s too late to hit the 2.6.28 release (the fix is fairly small, but very invasive), so it will go in early in the 2.6.29 merge window.

If there are no problems it would then possibly get back-ported to one of the 2.6.28.x stable trees.

A eso es a lo que llamo yo buenas noticias! Usuarios de linux en laptops / notebooks: Regocijáos! Por fin su linux va a volver a funcionar después de haber cerrado la tapa!