Reiniciar un servidor Linux con systemctl reiniciarParece sencillo. Un comando, una contraseña de sudo y la máquina se reinicia. El problema es que este reinicio también cierra las sesiones abiertas, las conexiones SSH, los procesos en ejecución y, a veces, un servicio que alguien estaba utilizando.
Por lo tanto, le recomiendo que considere el reinicio como una tarea de mantenimiento menor, incluso en una máquina personal o un VPS. El objetivo no es complicar un comando básico, sino comprobar qué se está ejecutando, proporcionar advertencias si es necesario y luego reiniciar correctamente sin descubrir demasiado tarde que había una tarea en curso.
¿Qué hace realmente systemctl reboot?
En una distribución moderna con systemd, systemctl reiniciar Le pide al sistema que reinicie la máquina. Es similar a un comando. reiniciar, pero usted pasa explícitamente por sistemad, que coordina el cierre de los servicios antes de su reinicio.
sudo systemctl rebootNo confundir con systemctl powerofflo que apaga la máquina, o systemctl haltque apaga el sistema sin necesariamente cortar la energía, dependiendo del hardware. Si su objetivo es reiniciar para aplicar una actualización del kernel, recargar una pila de red o comprobar un servicio al arrancar, systemctl reiniciar es la orden directa.
Si simplemente has modificado un archivo .servicioNo siempre es necesario reiniciar el sistema por completo. En ese caso, empieza por comprender la situación. Cuándo usar systemctl daemon-reloadLuego, reinicie únicamente el servicio en cuestión.
Compruebe las sesiones abiertas antes de cerrar sesión.
Antes de reiniciar un servidor, primero verifico quién está conectado. Es una tontería, pero evita desconectar accidentalmente la sesión de un compañero, interrumpir una transferencia SCP o interrumpir un comando ejecutado desde una terminal.
OMS
w
loginctl listar sesionesOMS Proporciona una vista rápida de los usuarios conectados. w añade lo que hacen. loginctl listar sesiones Es útil en un sistema systemd, especialmente si se desea identificar sesiones locales, SSH o gráficas.
En un servidor de producción, muestro una advertencia antes de reiniciar. Un simple anuncio es suficiente:
sudo wall "El servidor se reiniciará en 10 minutos para mantenimiento."Si eres el único usuario de un VPS, este paso podría parecer innecesario. Sin embargo, siempre lo tengo en cuenta cuando hay varias cuentas, acceso de clientes, un proceso de larga duración o una aplicación expuesta.
Supervisar los servicios y los trabajos en curso.
Un reinicio limpio no soluciona todos los problemas. Si un servicio ya presentaba fallos antes del reinicio, podría volver al mismo estado después. Prefiero comprobarlo previamente y luego comparar los resultados.
systemctl --failed
systemctl listar trabajos
systemctl está-en-ejecuciónsystemctl --failed Enumera las unidades que han fallado. systemctl listar trabajos muestra operaciones de systemd pendientes. systemctl está-en-ejecución proporciona un estado general, por ejemplo correr, degradado O a partir de.
Si observa que un servicio crítico está fallando, anote su nombre antes de reiniciarlo:
systemctl status nombre-del-servicio
journalctl -u nombre-de-servicio -b --no-pagerPara obtener una lista más completa de servicios y filtrar los que están activos o presentan fallas, también puede consultar la guía sobre… Comandos útiles de systemctl antes de un reinicio aleatorioEste es precisamente el tipo de verificación que evita confundir causa y efecto.
Planifica un reinicio en lugar de apagarlo inmediatamente.
systemctl reiniciar se reinicia inmediatamente. Si desea permitir un retraso, utilice en su lugar cerrar con la opción -r. EL -r significa reiniciar.
sudo shutdown -r +10 "Se espera el reinicio en 10 minutos"Para cancelar el reinicio programado:
sudo shutdown -cEste es mi método preferido cuando tengo la más mínima duda. Dedicas unos minutos a realizar una copia de seguridad, cerrar una sesión, notificar a un usuario o consultar un sistema de monitorización.
la documentacion de cerrar Sigue siendo útil si quieres entender los formatos de hora aceptados. Para sistemactlLa referencia de systemd está disponible en el Página oficial de systemctl.
Caso SSH: no reiniciar sin una red de seguridad
Si está conectado a través de SSH, el reinicio desconectará su sesión. Esto no es un problema si el servidor se reinicia correctamente. Se convierte en un problema si la red, el firewall, el disco o SSH No vuelvas a subir.
- Mantenga el acceso a la consola, KVM, IPMI, iDRAC, iLO o a la consola del proveedor, si es posible.
- Compruebe el espacio en disco antes de reiniciar si la máquina ya ha mostrado errores.
- Evite reiniciar inmediatamente después de un cambio de red no probado.
- Si ha modificado el cortafuegos, mantenga una regla de retorno o una sesión de root local.
En un VPS, también verifico que la consola web del proveedor funcione antes de ejecutar el comando. Solo toma 30 segundos y puede evitarte una solicitud de soporte frustrante.
Tras reiniciar el sistema, compruebe que la máquina ha vuelto a funcionar con normalidad.
Una vez restablecida la conexión, no dé por sentado que todo está bien solo porque SSH responde. Comience por comprobar el último arranque:
tiempo de actividad
systemctl está-en-ejecución
systemctl --failedA continuación, compruebe si hay errores durante el proceso de arranque actual:
journalctl -b -p advertencia..alerta --no-pagerSi desea comparar con el inicio anterior, utilice:
journalctl -b -1 -p advertencia..alerta --no-pagerla guía para journalctl y el último arranque de Linux Esta sección detalla si necesita investigar un arranque lento, un servicio que falla o un mensaje de hardware.
Mi lista de verificación antes de reiniciar Linux
OMSOwpara ver las sesiones abiertas.systemctl --failedpara tomar nota de los servicios que ya presentan errores.systemctl listar trabajospara evitar interrumpir una operación de systemd que se esté ejecutando actualmente.apagado -r +10Si desea permitir un retraso.- Acceso a la consola si trabajas de forma remota.
journalctl -bdespués de reiniciar para comprobar si hay errores.
En una estación de prueba, sudo systemctl reboot Eso suele ser suficiente. En un servidor, prefiero dedicar dos minutos a comprobar las sesiones y los servicios que ganar diez segundos persiguiendo una máquina que no responde.