systemctl reset-failed restablece el estado de fallo de una unidad y su contador de reinicios. El comando prepara un nuevo control, pero no repara el servicio.
Cuando una unidad de systemd pasa al estado failed, la tentación es ejecutar inmediatamente systemctl reset-failed. En una VM, un puesto o un servidor, este comando puede eliminar el estado visible sin abordar la causa de la parada.
El diagnóstico comienza por el estado del servicio y su registro. Luego podrá restablecer la unidad específica, verificar el resultado y luego intentar un arranque separado si se comprende el error.
Leer el servicio antes de restablecer su estado
Una unidad marcada como failed indica el estado rastreado por systemd. Por sí sola, no proporciona la razón del fallo. Comience por el estado y el registro con la unidad realmente implicada:
systemctl status mi-servicio.service
journalctl -u mi-servicio.serviceEl enlace journalctl permite encontrar el mensaje del servicio en el registro. Léalo antes de eliminar el estado failed, especialmente si la unidad reinicia en bucle.
Para separar el estado actual, el subestado, el resultado de la ejecución y el contador de reinicios, pida también las propiedades de la unidad:
systemctl show mi-servicio.service -p ActiveState -p SubState -p Result -p NRestartsEstos cuatro valores responden a preguntas diferentes:
ActiveStateindica el estado general rastreado por systemd.SubStateespecifica el subestado de la unidad.Resultindica el resultado de la ejecución que llevó al fallo.NRestartsda el número de reinicios registrados.
El comando reset-failed borra el estado, no el error
Después de la lectura, dirígete únicamente a la unidad afectada:
sudo systemctl reset-failed mi-servicio.servicesystemctl reset-failed <unidad> restablece el estado failed de la unidad y el contador de reinicios asociado a la limitación de arranque. El comando no reinicia la unidad.
No modifica ni ExecStart, ni los permisos, ni las dependencias, ni el binario utilizado por la unidad. Tampoco borra el registro. La página del manual de systemctl describe este comportamiento y los otros subcomandos disponibles.
La desaparición de failed puede dar, por tanto, una falsa impresión de reparación. El servicio aún puede contener una configuración inválida, una dependencia ausente o un comando ExecStart que falla.
Controlar el resultado antes de un nuevo arranque
Revise las propiedades después del restablecimiento. El control se centra en el estado de la unidad y en el contador, no en una salida de comando que copiar:
systemctl show mi-servicio.service -p ActiveState -p SubState -p Result -p NRestartsSi la causa se comprende y se corrige, el arranque se convierte en una acción distinta:
sudo systemctl start mi-servicio.service
systemctl status mi-servicio.service
journalctl -u mi-servicio.serviceEl estado y el registro permiten comprobar el estado obtenido después de este arranque. Si la unidad vuelve inmediatamente a fallar, detenga los intentos y corrija la causa indicada en Result o en el registro.
Recargue los archivos de unidad con sudo systemctl daemon-reload después de modificar un archivo de unidad. Este paso no sigue automáticamente a reset-failed. La carpeta dedicada a los recargas systemd trata este caso por separado.
Para un servicio lanzado por un temporizador, el funcionamiento de los temporizadores systemd explica la relación entre la unidad de servicio y su desencadenador. El estado restablecido no corrige ni el programa, ni la configuración, ni la dependencia que provoca el fallo.