¿Un servicio no arranca o falla una función? El estado y los registros del momento ayudan antes de que un reinicio cambie los indicios. Esta guía corresponde a sistemas con systemd. example.service representa el servicio afectado real.
Paso a paso
- Anota hora, zona horaria y función afectada. Obtén el nombre exacto de la unidad de la documentación o con
systemctl list-units --type=service --all. Los nombres varían entre distribuciones. - Lee
systemctl status example.service --no-pager --full. Distingue Loaded, Active y errores concretos. ‘enabled’ describe la activación al arrancar, no demuestra que la aplicación funcione bien ahora. - Lee
journalctl -u example.service -b -n 100 --no-pager. Limita la salida al arranque actual y las últimas 100 entradas coincidentes. Para un incidente anterior, puede excluir los mensajes necesarios. - Si hace falta, usa
journalctl -u example.service --since '2026-09-16 12:00:00' --until '2026-09-16 12:30:00' --no-pagery sustituye ambas horas. Comprueba la zona del sistema. Lee también los mensajes inmediatamente anteriores al fallo. - Para un servicio de usuario, usa
systemctl --user status example.serviceyjournalctl --user -u example.servicecon la cuenta afectada. La ausencia de entradas también puede indicar permisos insuficientes, otros archivos de registro o retención vencida.
Comprobar el resultado
Anota el primer error concreto, su hora y el estado del servicio. Prueba la función real por separado: ‘active’ no demuestra un inicio de sesión, petición o procesamiento correcto. Decide un siguiente ensayo dirigido, no reinicios arbitrarios.
Revertir y limitaciones
Estos comandos leen información sin modificar el servicio. Antes de reiniciar, cambiar configuración o usar reset-failed, aclara impacto y recuperación. Los registros pueden incluir información confidencial; comparte solo fragmentos necesarios y depurados.