Comando reiniciar Linux: reboot, shutdown -r now, systemctl

El comando de reinicio en Linux: reboot, shutdown -r now y systemctl reboot

En cualquier distribución actual los tres comandos siguientes reinician la máquina exactamente de la misma manera. Ejecuta uno de ellos como root o mediante sudo; por SSH, una cuenta sin privilegios obtiene Failed to reboot system via logind: Interactive authentication required.

sudo reboot
sudo shutdown -r now
sudo systemctl reboot

No se trata de tres implementaciones. En las distribuciones con systemd, /sbin/reboot, /sbin/shutdown, /sbin/halt y /sbin/poweroff son enlaces simbólicos a systemctl, que comprueba el nombre con el que se ha invocado y cambia al modo de compatibilidad correspondiente; ls -l $(which reboot) muestra el enlace. Escribas la forma que escribas, systemd arranca reboot.target, detiene todas las unidades en orden inverso de dependencias, desmonta los sistemas de archivos y pide al kernel que reinicie. Por SSH la conexión se corta en uno o dos segundos; cuánto tarda la máquina en volver depende del kernel, de una posible comprobación del sistema de archivos y de la ruta de arranque del proveedor, así que concédele un minuto antes de dar por hecho que hay un problema.

Apagar: shutdown -h now, poweroff, halt y el clásico init 6

Para apagar la máquina, cualquiera de estos vale:

sudo shutdown -h now
sudo poweroff          # identical to: sudo systemctl poweroff

Bajo systemd, -h significa "detener o apagar, lo que sea el valor por defecto", y el valor por defecto es apagar, así que shutdown -h now y shutdown -P now son idénticos. El comando que pilla a mucha gente es halt a secas: detiene el sistema operativo pero nunca envía la petición de apagado, así que una máquina virtual se queda en System halted, todavía asignada y todavía facturándose, hasta que la detienes desde el panel. Usa halt -p, poweroff o shutdown -h now en su lugar.

Las formas SysV siguen funcionando porque systemd asocia los runlevels a targets: init 6 y telinit 6 se resuelven en reboot.target, e init 0 en poweroff.target. Son inofensivas en un script antiguo, pero no ofrecen mensaje wall, ni programación, ni registro en el journal, así que no hay motivo para escribirlas a mano.

Programar un reinicio, cancelarlo y avisar a los usuarios conectados

sudo shutdown -r +10 "Kernel update, back in about two minutes"
sudo shutdown -r 02:30
sudo shutdown -c

La hora puede ser now, +m para m minutos a partir de ahora, o hh:mm en formato de 24 horas (una hora ya pasada hoy significa mañana). Sin ninguna hora, shutdown asume +1: un sudo shutdown a secas apaga la máquina en sesenta segundos. Todo lo que va después de la hora se difunde como mensaje wall a cada terminal conectado, y logind repite el aviso a medida que se acerca el plazo; --no-wall lo silencia, y shutdown -k envía el aviso sin programar nada. Cinco minutos antes del plazo, logind crea /run/nologin y a partir de ese momento se rechazan los nuevos inicios de sesión.

shutdown -c cancela la operación pendiente, elimina /run/nologin e informa a los usuarios conectados de que el apagado se ha cancelado. Para comprobar si hay uno pendiente, busca /run/systemd/shutdown/scheduled: solo existe mientras hay un apagado en cola y registra el modo y la hora prevista. Las versiones recientes de systemd también aceptan systemctl reboot --when=+10m, con --when=show y --when=cancel (comprueba systemctl --help; las versiones antiguas no lo tienen).

Qué les ocurre a los servicios y a las sesiones SSH durante un reinicio

Cuando se solicita reboot.target, systemd detiene todo lo que entra en conflicto con él, es decir, casi todas las unidades. Los servicios se detienen en orden inverso de dependencias: cada uno ejecuta su ExecStop o recibe SIGTERM, y si no ha terminado después de TimeoutStopSec (90 segundos por defecto, según DefaultTimeoutStopSec= en /etc/systemd/system.conf) recibe SIGKILL. Ese tiempo de espera es la cuenta atrás A stop job is running for ... que se ve en la consola; suele ser un demonio que ignora SIGTERM o una base de datos que aún está volcando datos. Después los sistemas de archivos se desmontan o se remontan en solo lectura y el kernel reinicia. No hace falta ejecutar sync antes.

Tu sesión SSH no recibe ningún trato especial. ssh.service se detiene, el scope que contiene tu sesión recibe SIGTERM, tu shell muere y el cliente imprime Connection to 203.0.113.10 closed by remote host. Un servidor tmux o screen te protege de una conexión caída, no de un reinicio: lo que se ejecuta dentro también desaparece.

Lo que vuelve lo decide la activación, no lo que estaba en ejecución. Las unidades marcadas como enabled se inician de nuevo; cualquier cosa lanzada a mano con systemctl start, un proceso nohup o un contenedor Docker sin política de reinicio, no. Ejecuta systemctl list-unit-files --state=enabled antes y systemctl --failed después; la guía sobre listar y filtrar servicios con systemctl explica cómo leer ambos.

Reiniciar un VPS con seguridad: la lista de comprobación previa

En un VPS no hay acceso físico, así que un reinicio que no vuelve significa un rodeo por la consola del proveedor. Cinco comprobaciones, menos de un minuto en total, evitan casi todos esos rodeos.

1. Confirma que el reinicio es realmente necesario

No todas las actualizaciones lo exigen. En Ubuntu, /var/run/reboot-required existe cuando un paquete ha pedido un reinicio y /var/run/reboot-required.pkgs indica cuál; needrestart en Debian y Ubuntu, y needs-restarting -r de dnf-utils en la familia RHEL, hacen la misma comprobación en otros sistemas. Un kernel, una glibc o un systemd nuevos justifican un reinicio; un nginx parcheado solo necesita systemctl restart nginx. Instala primero las actualizaciones pendientes para reiniciar una vez y no dos; el tutorial sobre actualizar Ubuntu desde la línea de comandos cubre la secuencia de apt y el indicador reboot-required.

[ -f /var/run/reboot-required ] && cat /var/run/reboot-required.pkgs
uname -r; ls /boot/vmlinuz-*     # running kernel vs. newest installed

2. Asegúrate de que nada está a mitad de escritura

Interrumpir un gestor de paquetes es el camino más rápido a un sistema medio configurado, y una copia de seguridad cortada a la mitad es un archivo que más adelante confundirás con una copia válida. Busca esos procesos y comprueba quién más está conectado:

pgrep -a 'apt|dpkg|dnf|yum|unattended'
pgrep -a 'rsync|mysqldump|pg_dump|restic|borg'
w

3. Valida la configuración que debe sobrevivir al arranque

Tres archivos convierten un reinicio rutinario en un bloqueo. Un error de sintaxis en sshd_config hace que sshd no arranque y no puedas volver a entrar: sudo sshd -t no imprime nada cuando el archivo es válido, y si acabas de reforzar el demonio SSH, ejecútalo ahora. Una entrada de /etc/fstab que apunta a un dispositivo que ya no existe hace que el arranque caiga en modo de emergencia salvo que lleve nofail; sudo findmnt --verify detecta la mayor parte de eso. Un /boot lleno puede dejar un kernel a medio instalar, así que comprueba su espacio libre. Las reglas de cortafuegos escritas directamente con iptables o nft y nunca guardadas desaparecen al reiniciar; las de UFW y firewalld persisten.

sudo sshd -t
sudo findmnt --verify
df -h / /boot

4. Toma una referencia inicial

systemctl --failed
systemctl list-units --type=service --state=running > ~/services-before.txt

5. Reinicia y después verifica

sudo systemctl reboot --message="post-update reboot"
# after reconnecting:
uptime -s; systemctl --failed
systemctl list-units --type=service --state=running | diff ~/services-before.txt -

Un uname -r coherente, un systemctl --failed limpio y un diff vacío significan que el reinicio ha hecho su trabajo.

Cuando el reinicio se queda colgado: forzarlo y cuándo usar la consola del proveedor

Si reboot devuelve el control pero la máquina nunca se apaga, hay un stop job atascado; systemctl list-jobs muestra cuál. systemctl reboot --force se salta la parada ordenada de las unidades: los procesos se matan sin más, pero los sistemas de archivos sí se desmontan, así que es brusco aunque razonablemente seguro. --force --force reinicia de inmediato sin desmontar nada y puede provocar pérdida de datos; considéralo como tirar del cable. La interfaz SysRq del kernel es el último recurso cuando ni siquiera systemd responde. Escribir en /proc/sysrq-trigger siempre está permitido para root, diga lo que diga el sysctl kernel.sysrq, pero la redirección debe ejecutarse como root, así que usa una shell de root o sudo sh -c:

echo s > /proc/sysrq-trigger   # sync dirty buffers
echo u > /proc/sysrq-trigger   # remount filesystems read-only
echo b > /proc/sysrq-trigger   # reboot right now

Recurre al panel o a la consola del proveedor cuando el sistema invitado ya no puede ayudarse a sí mismo: SSH inaccesible tras un cambio de red o de cortafuegos, un kernel que entra en pánico al arrancar, un prompt de modo de emergencia por una línea errónea en fstab, una contraseña de root olvidada. Reboot o Shutdown en un panel suelen enviar un evento de alimentación ACPI que el sistema invitado gestiona mediante logind (HandlePowerKey= en logind.conf), así que los servicios siguen deteniéndose de forma limpia. Reset, Force stop o Power cycle cortan la alimentación virtual sin aviso: el journal del sistema de archivos se reproduce en el siguiente arranque, pero todo lo no escrito se pierde. La consola VNC o serie es lo que te permite ver GRUB, los mensajes del kernel y la shell de emergencia que SSH nunca te muestra.

Comprobar el uptime y cuándo se reinició la máquina por última vez

uptime -p                      # up 3 days, 4 hours, 12 minutes
uptime -s                      # 2026-08-31 02:31:07
who -b                         # system boot  2026-08-31 02:31
last -x reboot shutdown | head
journalctl --list-boots

uptime -s y who -b imprimen directamente la hora de arranque. last -x lee /var/log/wtmp y lista tanto los registros reboot como los shutdown: una línea reboot sin una línea shutdown antes significa que la máquina cayó de forma sucia (un pánico o un reset forzado). journalctl --list-boots numera todos los arranques que conoce el journal, siendo 0 el actual y -1 el anterior; journalctl -b -1 -e muestra entonces las últimas líneas antes del apagado anterior, donde un timeout de stop job o una muerte por falta de memoria deja su rastro. Si solo aparece el arranque actual, el journal es volátil: crea /var/log/journal y reinicia systemd-journald.

Todos los comandos anteriores se apoyan en una suposición: que cuando el sistema invitado se niega a volver, todavía puedes alcanzarlo. Un VPS Linux KVM con acceso a consola te da exactamente eso: una máquina virtual real con su propio kernel, CPU y RAM dedicadas, root completo y una consola para los días en que SSH no es una opción. rdp.monster lo entrega unos 10 segundos después de la confirmación del pago, con ancho de banda ilimitado (uso razonable), sin KYC, aceptando tarjetas y cripto, desde $8.99/mes.