Solución a: «Dependency failed for…» en Linux (systemd)
Arrancás el sistema y en medio del proceso de boot aparece un mensaje en rojo: «Dependency failed for…». A veces el sistema sigue arrancando igual, pero algún servicio queda sin levantar. Otras veces te deja tirado en una pantalla de emergencia. En ambos casos, el mensaje por sí solo no te dice mucho.
Vamos a ver qué significa realmente, por qué pasa y cómo encontrar el servicio que lo está causando, en vez de reiniciar a ciegas esperando que se solucione solo.
¿Qué significa el error?
En systemd, muchos servicios necesitan que otro servicio (o un target, como network-online.target) esté activo antes de poder arrancar. Cuando ese requisito no se cumple, systemd no arranca el servicio dependiente y muestra «Dependency failed for [nombre del servicio]».
No es un error del servicio en sí, sino una consecuencia: algo de lo que depende falló antes, y systemd corta la cadena ahí para no dejar el sistema en un estado inconsistente.
¿Por qué ocurre?
- El servicio del que depende falló al arrancar (por ejemplo, un montaje de disco que no se completó).
- Un timeout: el servicio dependiente tardó demasiado en iniciar y systemd lo dio por fallido.
- Una unidad mal configurada, con un archivo .service editado a mano con errores de sintaxis.
- Un dispositivo o partición que ya no existe (por ejemplo, un disco externo que se desconectó) y que sigue referenciado en
/etc/fstab. - Actualizaciones del sistema que dejaron una unidad huérfana o desactualizada.
Solución paso a paso
Lo primero es identificar exactamente qué servicio falló y de qué depende. Sin este paso, cualquier solución es a ciegas.
systemctl --failedEste comando lista todas las unidades que fallaron en el arranque. Ahí vas a ver el nombre exacto del servicio problemático.
Con el nombre en mano, revisá su estado y las dependencias asociadas:
systemctl status nombre-del-servicio.serviceLa salida te muestra si el problema está en el propio servicio o en una unidad de la que depende (aparece como «Requires» o «After» en el detalle).
Para ver el historial completo de lo que pasó en ese servicio durante el arranque:
journalctl -u nombre-del-servicio.service -bEl flag -b limita el resultado al arranque actual, así no te mezclás con logs de sesiones anteriores.
Si el problema es un montaje de disco (muy común con discos externos o unidades de red en /etc/fstab), revisá el archivo:
cat /etc/fstabBuscá líneas que referencien discos que ya no están conectados. Si encontrás una, no la borres directamente: comentala primero anteponiendo #, guardá, y probá reiniciar. Si todo arranca bien, ahí confirmás que era esa la causa.
Si el problema es de sintaxis en un archivo de unidad personalizado, podés validarlo así:
systemd-analyze verify nombre-del-servicio.serviceEste comando te va a marcar exactamente qué línea o directiva está mal escrita.
Una vez corregida la causa raíz, recargá la configuración de systemd y volvé a intentar levantar el servicio:
sudo systemctl daemon-reload
sudo systemctl restart nombre-del-servicio.serviceCasos especiales
Si el servicio que falla es network-online.target o algo relacionado a red, es habitual en máquinas que arrancan antes de que la interfaz de red esté completamente lista, especialmente en Raspberry Pi o equipos con Wi-Fi. En esos casos conviene revisar si el servicio dependiente tiene configurado un timeout razonable, en vez de forzar el arranque sin red.
En servidores con discos de red (NFS, por ejemplo), el mismo error suele aparecer si el servidor remoto tarda en responder. Ahí la solución no está en el cliente sino en revisar la disponibilidad del recurso remoto.
Qué no hacer
- No deshabilitar el servicio dependiente solo para que el mensaje desaparezca; eso oculta el síntoma, no soluciona la causa.
- No editar archivos de unidad de systemd sin verificar la sintaxis después.
- No borrar líneas de
/etc/fstabsin antes comentarlas y confirmar que el sistema arranca bien.
Conclusión
«Dependency failed for…» casi nunca es el problema en sí, sino el efecto de otra falla anterior en la cadena de arranque. Con systemctl --failed y journalctl -u vas directo a la causa real, sin adivinar. Si después de corregir la causa el error sigue apareciendo en cada arranque, ahí sí vale la pena revisar si esa unidad tiene sentido en tu sistema o si quedó de una configuración vieja.
