Un servicio Linux no inicia: diagnosticar systemd antes de reiniciar

El estado fallido es el inicio del diagnóstico

Un servicio puede no iniciar porque systemd no encuentra la unidad, no puede interpretar su archivo, una dependencia falla o el proceso termina durante el arranque. El estado ayuda a separar esas posibilidades, pero no señala por sí solo una causa única. Primero conserva la evidencia del intento actual.

Los comandos de esta guía consultan estado y registros. Sustituye <unidad> por el nombre correcto, por ejemplo ssh o nginx. No los ejecutes contra un host ajeno ni compartas las salidas sin retirar datos sensibles.

1. Separa el estado de carga del estado de ejecución

systemctl status <unidad>.service --no-pager -l
systemctl show <unidad>.service -p LoadState -p ActiveState -p SubState -p Result -p ExecMainStatus -p NRestarts

status resume el estado de ejecución e incluye parte de los registros recientes. show devuelve propiedades concretas para revisar por separado la carga de la unidad, su estado y el resultado del proceso. El formato exacto y algunas propiedades pueden variar según la versión de systemd y el tipo de unidad.

• LoadState=not-found: confirma el nombre de la unidad y si el paquete o archivo correspondiente está instalado.
• LoadState=bad-setting: revisa errores de sintaxis o valores inválidos en la definición y sus archivos complementarios.
• ActiveState=failed: indica que la unidad falló, por ejemplo por salida de error, caída o tiempo de espera; no identifica por sí solo qué originó el fallo.
• ActiveState=inactive: puede significar que está detenida por diseño. Revisa el tipo de unidad y su objetivo antes de concluir que existe una avería.

2. Busca el primer error útil en el journal

journalctl -u <unidad>.service -b --no-pager -n 100
journalctl -u <unidad>.service -b -1 --no-pager -n 100
journalctl -u <unidad>.service --since "today 08:00" --no-pager

El primer comando limita la búsqueda a la unidad durante el arranque actual. El segundo consulta el arranque anterior, si esos registros siguen disponibles; su conservación depende de la configuración del journal. El tercero acota una ventana temporal. Compara las marcas de tiempo con el primer intento fallido, no solo con el último mensaje.

Si journalctl no muestra registros, valida el nombre de unidad, permisos de lectura y disponibilidad del journal. La falta de salida no prueba que el servicio no haya intentado iniciar.

3. Confirma qué definición de unidad está activa

systemctl cat <unidad>.service
systemctl list-dependencies <unidad>.service --all

cat muestra el archivo base y sus fragmentos complementarios conocidos por systemd. Las dependencias ayudan a localizar otro servicio o recurso que se espera antes del inicio. Compara la definición con el cambio más reciente y confirma que el servicio usa el archivo que estás revisando.

Inspecciona localmente rutas, usuario de ejecución, directorio de trabajo, permisos, archivos montados, variables necesarias y puertos. La propiedad ExecStart o los registros pueden contener secretos; no copies esos valores en tickets públicos ni en asistentes externos.

4. Valida una hipótesis antes de intervenir

Relaciona el primer error con una condición comprobable: archivo ausente, permiso insuficiente, dependencia no disponible, sintaxis inválida o proceso que devuelve un código de salida. Comprueba también espacio de disco, disponibilidad de recursos y cambios recientes en el paquete o configuración.

Antes de reiniciar o editar, guarda el estado observado y la versión actual de la configuración. En producción, acuerda ventana, impacto, responsable y reversión. Aplica un cambio por vez y compara el resultado con la misma señal usada en el diagnóstico.

No uses restart, enable, ni edites archivos como primer paso: esas acciones cambian estado o configuración y requieren entender la política de operación del servicio.

Alcance de esta revisión

systemctl informa sobre el estado de las unidades y journalctl consulta sus registros. Esas fuentes ayudan a acotar el problema, pero no reemplazan métricas, trazas, supervisión de dependencias ni pruebas de la aplicación. Los ejemplos de esta guía son ilustrativos; Elaine System no los ejecutó en un servidor de cliente.