Un servicio que pasa a fallido no necesita un reinicio inmediato. En un servidor, este hábito a veces borra el mensaje que explica la falla, o reinicia un programa con una configuración aún inválida.
Comience por identificar la unidad afectada, lea su estado y su registro, luego corrija la causa. La reinicio viene después.
Listar las unidades realmente en fallo
Este comando muestra los servicios y unidades que systemd considera defectuosos:
systemctl --failedAnote el nombre completo, por ejemplo nginx.service o mi-aplicacion.service. Una unidad exited no está necesariamente en fallo: algunos servicios ejecutan una tarea corta y luego se detienen normalmente. El estado failed indica que un inicio, un comando de control o un proceso supervisado ha terminado con un error.
Para revisar los servicios activos, detenidos y sus estados, consulte también la lista de servicios con systemctl.
Leer el estado del servicio antes de cualquier reinicio
Reemplace nginx por su unidad. La opción --no-pager imprime el resultado directamente en el terminal, lo que evita quedarse en less en una sesión SSH.
sudo systemctl status nginx --no-pagerPreste especial atención a la línea Active:, el código de salida y las últimas líneas mostradas. Un puerto ya ocupado, una ruta ausente, un certificado ilegible o una directiva mal escrita suelen aparecer aquí. Si el servicio inicia un binario que tiene su propio validador, ejecute primero este validador. Para Nginx, por ejemplo:
sudo nginx -tNo ejecute este comando en una máquina que no use Nginx. Cada servicio tiene su propia sintaxis de verificación.
Subir al mensaje de error con journalctl
systemctl status solo muestra un extracto. El registro de la unidad proporciona el contexto completo:
sudo journalctl -u nginx -b --no-pager
sudo journalctl -u nginx -n 50 --no-pager-b limita la búsqueda al arranque actual. -n 50 mantiene las 50 últimas líneas si la falla es más antigua. Para seguir un reinicio en vivo, use sudo journalctl -fu nginx en una segunda sesión SSH. La guía journalctl y los mensajes del último arranque ayuda a ampliar el diagnóstico cuando el error afecta a varios servicios.
Corregir, reiniciar y luego verificar
Después de una modificación del archivo de unidad o de un drop-in de systemd, recargue la configuración. Este paso no reinicia el servicio.
sudo systemctl daemon-reload
sudo systemctl restart nginx
systemctl is-active nginx
systemctl --failedis-active debe responder active. Si el servicio escucha en un puerto, también controle el puerto y realice una prueba desde el cliente correcto. Una respuesta active no garantiza que una aplicación web, un proxy o una base acepte ya las solicitudes.
En un servicio crítico, mantenga una segunda sesión SSH abierta antes de un reinicio y copie el error exacto en su ticket o notas. Evitará volver a hacer el mismo diagnóstico en el próximo incidente.