systemd rescue.target y emergency.target: cómo entrar en ellos y volver al funcionamiento normal

Objetivo

Arrancar en modo de rescate o de emergencia para reparar un sistema que no llega a su target normal y, después, volver al funcionamiento normal.

Requisitos previos

Acceso a la consola para añadir un parámetro de kernel en el menú de arranque. También hace falta la contraseña de root: ambos shells ejecutan sulogin, que la solicita, y si la cuenta root está bloqueada (el valor por defecto en Ubuntu), el shell se rechaza a menos que sulogin se ejecute con --force. Conviene prever esto antes de una interrupción del servicio, o bien usar un medio de rescate.

Pasos

1. Conocer la diferencia, según systemd.special(7): rescue.target "incorpora el sistema base (incluidos los montajes del sistema) y lanza un shell de rescate". La mayoría de los servicios no se inician, pero los sistemas de archivos están montados y la infraestructura básica está activa. emergency.target "inicia un shell de emergencia en la consola principal" y "no incorpora otros servicios ni montajes". Es la forma más minimalista de obtener un shell, comparable a init=/bin/sh, pero con un gestor de servicios operativo. systemd también entra en este modo por sí mismo cuando un sistema de archivos necesario no supera su comprobación o no se puede montar.
2. En el menú del cargador de arranque, editar la línea de comandos del kernel para un único arranque y añadir al final systemd.unit=rescue.target o systemd.unit=emergency.target (los alias single/1 seleccionan el modo de rescate y emergency selecciona el modo de emergencia). Es un cambio de una sola vez; no se escribe nada en el disco.
3. Tener en cuenta que el estado de montaje del sistema de archivos raíz en modo de emergencia depende de cómo se haya llegado a él: puede estar ya en solo lectura (por ejemplo, si arrancó con ro y falló antes de la etapa que lo vuelve a montar) o en lectura y escritura si la transición ocurrió después de establecerse los montajes normales. Antes de escribir nada, comprobarlo con mount | grep ' / ' y, si hace falta, volver a montar de forma explícita: mount -o remount,rw /.
4. Hacer la reparación (editar una línea rota de /etc/fstab, arreglar un servicio que falla en el arranque, corregir un error en /etc/default/grub). Una contraseña de root olvidada no se puede restablecer de este modo, porque para entrar se necesita. En sistemas basados en dracut, rd.break se detiene en cambio en el initramfs antes de cambiar de raíz, con la raíz real en /sysroot en solo lectura: mount -o remount,rw /sysroot, chroot /sysroot, passwd root y, en sistemas con SELinux, touch /.autorelabel antes de salir; de lo contrario, el siguiente arranque puede rechazar los inicios de sesión.
5. Volver al funcionamiento normal reiniciando (systemctl reboot, esta vez sin el parámetro systemd.unit=) o, desde el modo de rescate y sin reiniciar, con systemctl default (también escrito systemctl isolate default.target) para levantar el resto del sistema en la sesión actual.
6. Verificar: systemctl get-default informa del target predeterminado configurado, y systemctl list-units --failed debería estar vacío (o contener solo entradas esperadas) tras volver a él.

Resultado esperado

El sistema llega a un shell funcional de modo monousuario o de emergencia incluso cuando el arranque normal no puede completarse, y vuelve limpiamente a default.target una vez aplicada la corrección.

Límites y base de verificación

Ambos targets se alcanzan de la misma manera (systemd.unit=); confundir cuál de los dos se ha pedido es un error frecuente: el modo de rescate ofrece sistemas de archivos montados y servicios básicos, el de emergencia no. Un cambio de systemd.unit= en el menú de arranque nunca persiste más allá de ese único arranque; un cambio persistente corresponde a la configuración del cargador de arranque, no a este procedimiento.