Poesía binaria

En muchos sitios, podemos ver esta palabra clave, para muchos RESUIB para otros RESIUB y normalmente REISUB. Y sirve para reiniciar el sistema Linux de forma segura después de que el sistema se congele; de la siguiente forma: Alt+Imprimir Pantalla + R,E,I,S,U,B (no hace falta soltar las teclas Alt + Imprimir pantalla). Cada letra representa una acción del kernel:

• R (Devuelve el control al teclado unRaw)
• E (Termina todos los procesos tErm)
• I (Mata los procesos que queden vivos full kIll)
• S (Sincroniza los discos Sync)
• U (Monta todos los sistemas de archivos como sólo lectura Umount)
• B (Reinicia el ordenador Boot)

Bien, si tenemos acceso físico al ordenador, no hay problema, pero y si estamos enchufados en otra máquina ? Todo está en el fichero especial /proc/sysrq-trigger.

Obteniendo información de los procesos

Enviando a /proc/sysrq-trigger (como root) la letra correspondiente a la acción del kernel vale. Empezaremos pidiendo ayuda:

root $ echo “h” > /proc/sysrq-trigger

root $ dmesg | tail

…. # Nos dirá muchas cosas, sólo nos interesa la última línea
SysRq : HELP : loglevel0-8 reBoot tErm Full kIll saK showMem Nice powerOff showPc show-all-timers(Q) unRaw Sync showTasks Unmount shoW-blocked-tasks

Vemos cómo el kernel a través de dmesg se comunicará con nosotros. Cada letra mayúscula nos indicará una acción diferente, empezaremos obteniendo información sobre la memoria:

root $ echo “m” > /proc/sysrq-trigger

root $ dmesg | tail -n 35

O información sobre tareas bloqueadas:

root $ echo “m” > /proc/sysrq-trigger

root $ dmesg

Más acciones

Incluso podemos lanzar el OOM killer con la siguiente línea:

root $ echo “f” > /proc/sysrq-trigger

Terminar todos los procesos (igual que comentábamos arriba del todo):

root $ echo “e” > /proc/sysrq-trigger

Cambia el nivel de información de dmesg (del 0 al 8):

root $ echo 5 > /proc/sysrq-trigger

Para enviar un REISUB es algo más elaborado:

root $ nohup bash -c “for key in s u b; do echo \$key > /proc/sysrq-trigger; sleep 4; done”

Aunque tendremos que asegurarnos de que las tareas estén muertas, ya que, nuestra conexión ssh, o nuestro terminal, o incluso bash, se mueren al mandar un E o un I al kernel (dando igual el nohup). Por otra parte, la R la podemos quitar, ya que vale para devolver el control al teclado, y estamos desde un equipo remoto.

Seguridad

Pero tanto por nosotros mismos (debemos de protegernos de meter la pata), como los posibles usuarios del ordenador, tal vez no nos interese que puedan pulsar en teclado alguna combinación de teclas que comprometa al kernel. Para ello, tenemos  /proc/sys/kernel/sysrq o directamente el comando sysctl del cual modificamos la propiedad kernel.sysrq; lo haremos de la siguiente manera:

root $ sysctl kernel.sysrq=0 # Para desactivar Alt+SysRq

root $ sysctl kernel.sysrq=1 # Para activarlo

Se pueden activar algunos comandos sólo, dependiendo del número que se indique.

Esto está basado en una conversación real. Hace un tiempo, encontré a una de esas personas, que yo llamo cariñosamente, un gafe informático, tras comprarse el primer ordenador, tuvo mala suerte instalando Windows (Millenium, sé que todos tenemos un amigo de un amigo al que le ha funcionado bien esta versión, pero no fue el caso de esta persona), cada poco tiempo le fallaba casi sin hacer nada, de estas veces que instalas cuatro programas locos que has instalado varias veces en varios ordenadores y en el ordenador de esa persona no entran. El problema no era fácilmente reproducible, ya que sólo pasaba a veces; pero aún así, con muchos problemas, aguantó un año con el ordenador.

Al año siguiente compró otro, y al instalar Windows XP, tuvo varios problemas, y hubo que devolver a la tienda el ordenador por errores de hardware (hasta que al final se lo dieron instalado y todo), y en cuestión de un par de meses, Windows empezó a dar pantallazos azules, al reinstalar, seguía dando pantallazos, esta vez por culpa de la actualización de un driver de la placa base. Sin él, el ordenador funcionaba, aunque el USB2.0 no funcionaba, y el disco duro iba un poco más lento, siguió con el mismo Windows XP que reinstalaba manualmente cada 3 meses (no hacía un uso intensivo del ordenador, no instalaba muchos programas, aunque sí usaba Internet Explorer).

Compró también un portátil, tenía un problema en la RAM, que más tarde verifiqué personalmente; aunque mientras duraba la garantía, los del servicio técnico, en los numerosos partes de reparación (y los numerosos viajes que se pegó el portátil antes de funcionar), decían que le habían cambiado la CPU, el teclado, la placa base (este no me lo creí), la batería un par de veces… (esta historia acabó en denuncia e indemnización)

Fue el momento en que conocí a esta persona, y le propuse una forma de reinstalar Windows más rápida que a la antigua usanza, haciendo imágenes de la partición de sistema (algún día hablaré de esto), el tema es que verifiqué con un live CD de linux, que el USB 2.0 de su ordenador iba perfectamente, la transferencia de datos también, y tras usarlo mi amigo durante un rato, me dijo que su ordenador nunca había ido tan rápido. En este momento, le propuse probar Linux durante un mes y la cosa fue así:
- Es muy difícil - A.
- Sólo cambian los nombres de algunos programas y el botón de Inicio, que no pone Inicio - Yo (le enseñé un sistema KDE)
- Sí, pero la consola es de escribir mucho - A.
- Bueno, pero no hay por qué utilizarla - Yo
- Pero si la tiene, será para algo - A.
- Sí, es como la de Windows, pero ésta hace más cosas - Yo
- Claro, pero hay que aprender más cosas para saber aprovechar todas sus características - A.
- Bueno, pero tienes el registro de Windows, las políticas de acceso, los servicios de sistema, etc; que seguro que ni los has tocado - Yo.
- Cierto, pero al no estar a la vista, no tengo por qué conocerlo - A.

(Por cierto, la A. es de Amigo)

En fin, una conversación que se alargó un poco más de forma improductiva, después de que Linux se ahorrara unas 4 horas al mes en reinstalaciones de disco duro (con lo de la imagen de sistema y partimage), rescatara una partición de Windows cuando XP dejó de detectarla (no lo sé, de un arranque a otro la partición desapareció, pero Testdisk la rescató cuando ningún programa para Windows fue capaz), y sobre todo cuando con Linux, estuve trabajando unas horas con su primer ordenador sin ningún problema.

Me he encontrado a varias personas que no quieren probar Linux, ni algo que no sea Windows, a pesar de las malas experiencias. Aunque los que somos usuarios o conocemos bien este sistema, veamos que para un uso más o menos normal (navegación, ofimática, grabación de discos y alguna cosa más), no se necesita ningún conocimiento especial, ni siquiera hay que mirar la consola. Es más algunas distribuciones nos detectan e instalan el hardware que enchufamos automáticamente, pero aún así, y después de mostrar estas características, muchos se muestran rehacios al cambio; muchos aún son cautivos de la frase: “Más vale malo conocido que bueno por conocer”, sin ninguna razón sólida; aunque cada vez encuentro más personas que se sienten incómodas con el Windows de toda la vida, con el mantenimiento que requiere, y con que se pierde tiempo y energía, y en el que muchas cosas que en cualquier otro sitio se solucionan con un pequeño script, en Windows requieren un programa y varios Megabytes.

Quiero dedicar este post a cosas que me han llamado la atención estos últimos días:

1. Google se derrumba: Lo descubrí gracias a novatillasku. Es una tontería chulísima, la página principal de Google se cae a pedazos, aunque para verlo tendréis que utilizar un navegador decente. Abstenerse Internet Explorer. Click aqui para verlo.
2. Mapas de Karnaugh: Via Acerca de Ubuntu veo una serie de programas para resolver mapas de Karnaugh y ser el terror de la electrónica digital
3. Piedra, papel, tijeras, lagarto, Spock: Últimamente estoy viendo la serie The Big Bang Theory, ya estaba tardando en empezarla, y hace poco vi este post. Pocos días antes de llegar hasta el capítulo 2×08 donde ocurre todo
4. Acceder a un Array como un objeto [PHP]: El post ya tiene tiempo. Leído en el blog de Sergi Quiñonero. Nos cuenta cómo haciendo $objeto = (object) $array podemos acceder a cada elemento del array con -> (flechas) como si fuera un objeto.
5. El sistema Solar en HTML5. Muy currado, demostrando qué es capaz de hacer HTML5, y demasiado cool para IE, aunque está gracioso ver cómo se dibujan en Internet Explorer las órbitas cuadradas Ya sé que tampoco son redondas, pero es una demostración sólo…
6. Dos artículos de un blog muy interesante: Hace mucho tiempo que sigo el blog Buenhabit, y quiero destacar dos de sus últimos posts: Sólo dos cosas a la vez, que habla de una reciente investigación acerca de la limitación humana de la multitarea; y Si gritas no convences, merece la pena leerlo aunque el título lo diga todo.

Hasta aquí una pequeña selección de estos últimos días.

Hoy en día no se le suele ver la cara, dado que la memoria de nuestro sistema suele ser grande, pero cuando por ejemplo, a un proceso se le va la mano y reserva más memoria de la que tiene nuestro sistema, entra en marcha un proceso especial del núcleo de Linux; el OOM Killer (Out Of Memory Killer), que se encarga de detectar qué proceso es el peor del sistema y matarlo.
Atendiendo a la documentación (oom_kill.c) tendremos tres opciones cuando nos quedamos sin memoria:

• Matar un proceso al azar (malo)
• Congelar el sistema (peor)
• Matar un proceso de forma inteligente

En fin, si el sistema no está configurado para congelarse (sysctl.kernel_panic_on_oom), intentaremos ver qué proceso tiene más papeletas para morir (el más dañino), y se hace asignando puntuaciones a procesos, en definitiva queremos matar un proceso malo en beneficio para el sistema, no queremos fastidiar diez horas de trabajo frente al ordenador (a menos que sea necesario).

Se sigue el siguiente algoritmo:

• Los primeros puntos a sumar son la cantidad de memoria del proceso
• Sumamos la memoria independiente de sus procesos hijos
• Los procesos con prioridad (nice) duplican la puntuación. Un proceso con nice si se come nuestra memoria compromete el sistema.
• Los procesos de superusuario dividen por 4 la puntuación. Los procesos de sistema o de superusuario no deberían dar ningún problema, y si root ejecutara algo… él/ella sabe lo que hace
• Miramos el valor de /proc/ /oom_adj (comprendido entre -17 y +15). Como usuarios, podemos aumentar o disminuir la probabilidad de que un proceso salga elegido para su sacrificio (por el bien del sistema). Si escribimos en ese fichero un -17, nuestro proceso no va a matarlo nunca el OOM killer

Como buen Linux, que nos deja como usuarios poder tocar su funcionamiento, tenemos lo siguiente:

• /proc/PID/oom_score : Puntuación de un proceso
• /proc/PID/oom_adj : Asignar o quitar papeletas para que un proceso sea sacrificado (como dije en la lista anterior). Es buena idea que si sabemos que un proceso puede colgar nuestro sistema, le demos un +15; si el sistema se lo carga, mejor; y si es algo importante aunque nuestro sistema ande falto de memoria, le damos un -17
• sysctl vm.panic_on_oom : En lugar de matar un proceso, lanza un kernel panic.
• Hay más reglas para configuración si buscamos dentro de sysctl y /proc/

¿Queremos saber qué proceso tiene, ahora mismo, más papeletas para ser sacrificado?
Si disponemos de /proc/sys/vm/oom_victim lo podremos ver ahí, si no, podemos ejecutar este script:

Y lo más importante, queremos lanzarlo a mano, es decir, hay un proceso gastando mucha memoria y procesador, tanta, que no podemos hacer login en el sistema desde consola. Podemos hacer: Alt + SysRq + F y saltará un OMM Manual (Si sysctl kernel.sysrq = 1), es normal que se muera Firefox (gasta muchos recursos y Linux lo considera dañino para el sistema)

Foto: Joe Shlabotnik (Flickr)