systemctl failed: cómo descubrir por qué un servicio Linux no arranca
Publicado el 2026-10-26 por frfrand
Depurar servicios systemd con status, journalctl y permisos
Hacés deploy, el panel dice que el build terminó y tu dominio devuelve 502. Muchas veces el problema está un nivel más abajo: el servicio que ejecuta la API nunca arrancó o se cayó enseguida.
Te muestro dónde está el problema, cómo comprobarlo sin adivinar y qué haría en una aplicación que de verdad tiene usuarios. No necesitás memorizar un manual entero para resolver un fallo concreto.
Qué significa systemctl failed en la práctica
systemd supervisa servicios y expone su estado mediante systemctl. Un servicio failed puede deberse a una ruta equivocada, permisos, variables de entorno, puerto ocupado o una excepción en el código. El estado no revela siempre la causa: para eso están los logs.
Una aclaración antes de tocar el servidor: si el proyecto ya está en producción, guardá el estado que encontraste y comprobá en qué usuario y máquina vas a ejecutar los comandos. Trabajar como root sin necesidad y cambiar varias cosas a la vez dificulta encontrar la causa de un error.
Comandos útiles para empezar
sudo systemctl status miapp --no-pager
sudo journalctl -u miapp -n 80 --no-pager
sudo systemctl cat miapp
sudo ss -ltnp
# Tras corregir un archivo .service
sudo systemctl daemon-reload
sudo systemctl restart miappLas rutas, nombres de unidades y dominios son ejemplos. Adaptalos a tu servicio. Si un comando requiere permisos de administrador, revisá qué cambia y por qué. Las consultas de diagnóstico deberían venir antes de las modificaciones.
Paso a paso, con comprobaciones
- Comprueba la unidad exacta con
systemctl status. - Lee los logs en torno a la última ejecución y localiza el primer error concreto.
- Revisa
ExecStart,WorkingDirectory,Usery el archivo de variables, sin imprimir secretos. - Si cambiaste la unidad, ejecuta
daemon-reloadantes de reiniciar. - Verifica el puerto local y la ruta
/healthantes de volver a mirar el dominio.
Después de cada paso, verifica un resultado observable: un estado, un archivo, una respuesta HTTP o una entrada de log. Si encuentras un mensaje inesperado, guárdalo para investigar en lugar de ocultarlo con reinicios repetidos.
Ejemplo real: una aplicación que hay que mantener
Django funcionaba antes de actualizar dependencias. Al reiniciar, Gunicorn falla porque cambió la ruta del entorno virtual. El log dice No such file or directory; dar más RAM no arreglaría nada.
Al final, prueba el camino completo: entrar por dominio, llamar a la API, escribir un dato de prueba y verificar que la información sigue ahí tras un reinicio controlado. Un servidor que «arranca» no siempre es una aplicación que funciona.
Errores que vale la pena evitar
Reiniciar constantemente sin leer logs puede esconder el fallo y generar más cortes. Si el error proviene de una migración de datos, reinstalar el servicio no solucionará la incompatibilidad.
También es importante que las credenciales no terminen en el historial de la terminal, logs, archivos compartidos o capturas. Para usuarios y servicios, usa permisos mínimos y documenta quién puede revocar el acceso.
Cómo entra ArduMaker en este escenario
ArduMaker facilita observar y administrar servicios dentro del VPS; anota unidad y commit desplegado para relacionar un 502 con el cambio que lo causó.
ArduMaker puede ayudarte a administrar los VPS, desplegar repositorios y trabajar con servicios, bases y dominios desde la misma plataforma. No reemplaza lo que acabamos de explicar sobre Linux: precisamente por eso conviene entender el diagnóstico y tener una forma de repetirlo.
Cuándo conviene automatizarlo
Si la tarea se repite, documenta primero el procedimiento manual y sus comprobaciones. Después considera un script o una tarea programada con errores visibles, logs y permisos limitados. No automatices un comando que todavía no sepas recuperar cuando sale mal.
Preguntas habituales
¿Puedo probarlo sin afectar clientes? En muchos casos sí: un VPS de staging o un servicio de prueba separado permite validar la configuración antes de cambiar producción.
¿Cómo sé si quedó bien? Mira logs y una operación funcional, no solamente que el comando terminó con código cero.
¿Cuándo necesito más recursos? Cuando las métricas indiquen saturación de CPU, RAM, disco o conexiones. Un fallo de configuración rara vez se arregla contratando más memoria.
Referencias
En una frase: primero entiende el error, después cambia una cosa concreta y comprueba su efecto. Esa disciplina te ahorra muchas horas de soporte.