Linux congelado: cómo rescatar el escritorio sin reiniciar
Un escritorio Linux que deja de responder casi nunca exige pulsar el botón de apagado: en la mayoría de los casos se puede recuperar desde una consola de texto en pocos minutos. Esta lección es el relato de un cuelgue real en un ordenador de sobremesa con Linux Mint 22.3 y 13 GB de RAM, y de los pasos que permitieron rescatarlo sin perder nada.
El síntoma: el ratón se mueve, pero nada responde
El puntero se desplaza con normalidad por la pantalla, pero ningún clic tiene efecto. Ni ventanas, ni menús, ni el panel inferior. Es un síntoma engañoso: el puntero lo mueve directamente el servidor gráfico, así que puede seguir funcionando aunque el resto del sistema esté bloqueado.
La tentación en ese momento es mantener pulsado el botón de encendido. Funciona, pero supone perder todo lo que no estuviera guardado y arriesga dejar archivos a medio escribir. Antes de eso hay varias salidas, que conviene probar de menor a mayor impacto. Y antes incluso de la primera, a veces basta con esperar unos minutos a que el sistema se recomponga solo.
Primer intento: recargar el escritorio
Linux Mint usa el entorno de escritorio Cinnamon, que tiene un atajo para reiniciarse a sí mismo sin cerrar los programas abiertos: Ctrl+Alt+Esc. La pantalla parpadea y el escritorio vuelve a cargarse. Cuando el problema es un fallo del propio escritorio, suele bastar.
Una alternativa conocida desde Ubuntu (con GNOME) es Alt+F2, que abre un pequeño cuadro para escribir un comando. En Cinnamon, escribir ahí solo la letra r y pulsar Intro tiene el mismo efecto de recarga. En GNOME el truco solo funciona en sesiones X11, no en las que usan Wayland, que es lo habitual en las versiones recientes de Ubuntu.
Ambas soluciones dependen de que el escritorio todavía pueda reaccionar, y no siempre es así. Cuando la causa del cuelgue es la falta de memoria, el escritorio tampoco tiene recursos para recargarse.
Hay un caso más leve con solución propia: cuando el escritorio responde y solo está bloqueado un programa. Para eso existe xkill, que se lanza desde Alt+F2 o desde una terminal. El puntero se convierte en una cruz o una calavera, y el programa sobre el que se hace clic se cierra en el acto. Funciona en Cinnamon y en otros escritorios que usan X11, pero no en los que usan Wayland.
La puerta de atrás: la consola de texto
Linux mantiene varias consolas de texto (las llamadas TTY) que funcionan al margen del entorno gráfico. Se accede a ellas con Ctrl+Alt+F2 (también F3, F4...). Aparece una pantalla negra que pide usuario y contraseña, como en los ordenadores de hace treinta años.
Nota: en Ubuntu con GNOME la propia sesión gráfica suele ocupar la consola 2, así que Ctrl+Alt+F2 no saca del escritorio. En ese caso hay que usar Ctrl+Alt+F3.
Aquí hay que tener paciencia: la consola puede tardar bastante en aparecer, hasta el punto de hacer pensar que no funciona. Conviene esperar uno o dos minutos antes de darla por perdida.
Una vez abierta la consola, puede aparecer un mensaje como este:
Out of memory: Killed process 59118 (chrome)El núcleo del sistema avisa de que se ha quedado sin memoria y ha matado por su cuenta un proceso, en este ejemplo de Chrome, para sobrevivir. Eso explica tanto el cuelgue como la lentitud: con la memoria agotada, el sistema dedica casi todo su tiempo a mover datos entre la RAM y el disco, y cualquier tarea nueva, incluso comprobar una contraseña, tiene que esperar turno.
Que el proceso eliminado sea de Chrome no significa necesariamente que Chrome sea el culpable. Chrome marca sus pestañas como candidatas preferentes a ser eliminadas, precisamente para que el núcleo sacrifique una pestaña antes que otra cosa, así que suelen caer las primeras aunque haya otro programa ocupando todavía más memoria.
Diagnóstico: buscar al que se come la memoria
Con la consola ya abierta, lo más inmediato es cerrar el programa que señala el aviso y comprobar el estado de la memoria:
pkill chrome
free -hLo normal es encontrar apenas unos cientos de megas de RAM disponibles y el espacio de intercambio (swap), una zona del disco que el sistema usa como memoria de reserva, casi lleno. En el caso que dio origen a esta lección, cerrar Chrome no bastó. Tampoco lo arregló forzar el cierre con pkill -9 chrome: la memoria disponible apenas subió.
Hay que averiguar entonces quién está ocupando la memoria. Este comando lista los procesos ordenados de mayor a menor consumo y muestra solo los primeros:
ps aux --sort=-%mem | head -n 10En nuestro caso, la columna %MEM dio la respuesta: el culpable principal no era Chrome, sino Firefox. Su proceso principal ocupaba por sí solo el 25,5 % de la RAM, unos 3,5 GB, y de él colgaban muchos procesos más, más o menos uno por cada web abierta. Chrome y Firefox abiertos a la vez habían llenado entre los dos toda la memoria.
Para cerrar Firefox basta con el número de su proceso principal, que aparece en la columna PID (en el ejemplo, 3719):
kill 3719Es preferible no añadir -9 en este caso. Sin él, Firefox recibe una petición de cierre ordenado, guarda la sesión y, al volver a abrirlo, recupera todas las pestañas. Al cerrarse el proceso principal se cierran también todos los que dependen de él.
Un nuevo free -h mostró 11 GB disponibles. Con Ctrl+Alt+F7 (en algunos sistemas, Ctrl+Alt+F1 o Ctrl+Alt+F2) se vuelve al escritorio gráfico, que ya respondía con normalidad. Sin reiniciar y sin perder nada.
Pocas pestañas, mucha memoria
Lo llamativo del caso es que Firefox no tenía muchas pestañas abiertas, pero llevaba unas ocho horas en marcha. El número de pestañas importa menos que su tipo.
Las webs que actualizan datos y gráficos en tiempo real, como las de cotizaciones, las que cargan mucha publicidad y vídeo, como muchos periódicos, y los juegos en el navegador suelen ir acumulando memoria sin liberarla.
Tras el cierre ya no es posible saber qué pestaña provocó el problema, porque ese desglose se pierde con el proceso. Para vigilar el consumo antes de llegar al cuelgue, Firefox tiene una herramienta propia: escribiendo about:processes en la barra de direcciones aparece la memoria que gasta cada pestaña. Si una de ellas no deja de crecer, el culpable está identificado. Chrome ofrece algo parecido con Mayús+Esc.
Cómo evitar que se repita
Linux ya tiene un mecanismo para estos casos, el llamado OOM killer, que mata procesos cuando la memoria se agota. El problema es que actúa tarde: para entonces el sistema lleva minutos atascado y el usuario ha perdido el control. Hay dos medidas complementarias.
earlyoom
La más eficaz es instalar earlyoom, un pequeño programa que vigila la memoria y, cuando está a punto de agotarse, cierra el proceso que más gasta antes de que el escritorio se congele. Hace lo mismo que el núcleo, pero a tiempo. Se instala con un solo comando, arranca solo con el sistema y apenas consume recursos:
sudo apt install earlyoomPara comprobar que está activo: systemctl status earlyoom, que debe mostrar "active (running)".
Nota: Ubuntu, desde la versión 22.04, trae activado de serie systemd-oomd, que cumple una función parecida. Antes de instalar earlyoom conviene comprobarlo con systemctl status systemd-oomd: no tiene sentido tener los dos vigilando a la vez.
Ampliar el swap
La segunda medida es ampliar el swap. Linux Mint suele crear un archivo de intercambio de 2 GB, que en equipos con poca RAM se puede quedar corto. Ampliarlo no ralentiza el ordenador: el swap solo se usa cuando la RAM se llena. En ese caso el sistema irá más lento durante un rato, pero sin llegar al bloqueo total, lo que da margen para cerrar algo. Tras comprobar con swapon --show que el sistema usa el archivo /swapfile, estos comandos lo amplían a 8 GB:
sudo swapoff /swapfile
sudo fallocate -l 8G /swapfile
sudo chmod 600 /swapfile
sudo mkswap /swapfile
sudo swapon /swapfileConviene hacerlo con el equipo desahogado, con pocos programas abiertos: swapoff tiene que devolver a la RAM todo lo que haya en el swap en ese momento, y si no cabe, falla.
El cambio es permanente, porque el archivo ya está declarado en /etc/fstab para cargarse al arrancar. Si solo se va a aplicar una de las dos medidas, earlyoom es la que de verdad evita el cuelgue.
Resumen: qué hacer si el escritorio se congela
- Probar a recargar el escritorio con Ctrl+Alt+Esc (en Cinnamon) o Alt+F2 seguido de
r. - Si no responde, abrir una consola con Ctrl+Alt+F2 (F3 en Ubuntu) y esperar con paciencia, aunque tarde uno o dos minutos.
- Iniciar sesión y comprobar la memoria con
free -h. - Localizar el proceso que más gasta con
ps aux --sort=-%mem | head -n 10. - Cerrarlo con
killseguido de su número de proceso (PID), y solo si se resiste, conkill -9. - Volver al escritorio con Ctrl+Alt+F7 o Ctrl+Alt+F1.
- Si nada de lo anterior funciona, recurrir a las opciones de la sección siguiente antes que al botón de apagado.
Y para no tener que llegar a esto: instalar earlyoom.
Si nada de esto sirve
- Entrar desde otro dispositivo por SSH. Si el ordenador tiene instalado el servidor SSH (
sudo apt install openssh-server), se puede abrir una sesión desde otro ordenador o desde el móvil con una aplicación como Termux o JuiceSSH y cerrar el proceso culpable con los mismos comandos. A veces la red responde aunque la pantalla y el teclado parezcan muertos. - Forzar el OOM killer a mano. La combinación Alt+ImprPant+F ordena al núcleo que mate en ese mismo instante el proceso que más memoria ocupa, sin esperar a que lo decida él. En Ubuntu y Linux Mint esta combinación viene desactivada, así que solo sirve si se ha habilitado antes, como se explica más abajo.
- Reiniciar de forma ordenada con REISUB. Manteniendo Alt+ImprPant, se teclean despacio, con un par de segundos entre cada una, las letras R E I S U B. Por este orden, el sistema recupera el teclado, pide a los programas que se cierren, los fuerza si no lo hacen, guarda en disco lo pendiente, deja los discos en modo solo lectura y reinicia. Es mucho más seguro que el botón de apagado.
- El botón de encendido. Mantenerlo pulsado unos cinco segundos. Es el último recurso, con riesgo de perder datos no guardados.
Un aviso sobre las combinaciones con ImprPant, llamadas teclas mágicas (SysRq): Ubuntu y Linux Mint solo dejan activas algunas por seguridad. Por defecto funcionan S, U y B, así que REISUB reinicia el equipo guardando los datos pendientes en disco, aunque se salta en silencio el cierre ordenado de los programas. Las letras R, E, I y F no hacen nada hasta que se habilitan, y conviene prepararlo antes de necesitarlo:
echo "kernel.sysrq=1" | sudo tee /etc/sysctl.d/90-sysrq.conf
sudo sysctl --systemOtros tipos de cuelgue
La falta de memoria es una causa frecuente, pero no la única. Estas son otras pistas útiles cuando el síntoma es distinto o el problema se repite.
Investigar después qué pasó
Si hubo que reiniciar, el registro de la sesión anterior sigue guardado. Este comando muestra los errores que se produjeron en ella:
journalctl -b -1 -p errY este busca avisos de memoria como el de esta lección:
journalctl -k -b -1 | grep -i memoryEs la forma de saber a posteriori si el culpable fue la memoria, un controlador o el hardware.
Cuelgues totales, con el ratón también parado
Ese síntoma apunta a otra cosa: el controlador gráfico, el núcleo o el hardware. Las tarjetas NVIDIA con controlador privativo son un sospechoso habitual. Si el problema empezó tras una actualización, Linux Mint conserva los núcleos anteriores: en el menú de arranque GRUB, dentro de "Opciones avanzadas", se puede arrancar con uno previo para comprobarlo. Si el menú no aparece al encender, se muestra manteniendo pulsada Mayús (o pulsando Esc en equipos UEFI) durante el arranque. Y Timeshift, que Mint incluye de serie, permite volver a una instantánea del sistema anterior a la actualización, siempre que se haya configurado.
El disco lleno
Una partición del sistema al 100 % provoca bloqueos y comportamientos extraños que no parecen tener relación con el espacio. Se comprueba con df -h, fijándose en la línea cuyo punto de montaje es /.
Las causas físicas
Un sobrecalentamiento se detecta con sensors, del paquete lm-sensors, que muestra la temperatura del procesador. Una memoria RAM defectuosa se comprueba con Memtest86+, disponible como opción en el propio menú GRUB de Mint. Y un disco que empieza a fallar se descubre en la aplicación Discos, con la opción de datos SMART.
En la próxima lección: Salud de los discos duros: cómo leer los datos SMART con smartctl y por qué un disco que dice PASSED no siempre es de fiar.