The error message "Dependency failed: Runs server" indicates that a systemd service unit cannot start because its required dependencies, such as other services, network interfaces, or hardware resources, are not in the expected active state. This is a common Linux system log issue where the init system blocks execution to prevent cascading failures or data corruption. To resolve this, you must identify the specific missing dependency using diagnostic commands and then either fix the underlying resource issue or adjust the service configuration to handle the failure gracefully.
Understanding Systemd Dependency Failures
In modern Linux distributions, the
systemd init system manages service startup sequences based on a complex web of dependencies. When a service fails to start with a message like "Dependency failed," it means one or more units listed in its
Requires=,
Wants=, or
After= directives did not meet their target state. For example, if a web server depends on the network being fully configured, but the network manager is still initializing or has failed, the web server will be blocked from starting.
This behavior is intentional. It prevents applications from running in an inconsistent state where critical resources are unavailable. However, for administrators, these errors can obscure the root cause. The error message itself is often generic, pointing only to the immediate failure rather than the deeper reason why the dependency was not met. Therefore, troubleshooting requires digging into the logs to find the actual failing component.
Distinguishing Between Requires and Wants
It is crucial to understand the difference between hard and soft dependencies. A
Requires= directive creates a hard dependency; if the required unit fails, your service will also fail to start. A
Wants= directive creates a soft dependency; if the wanted unit fails, your service will still attempt to start, though it might behave unexpectedly. The "Dependency failed" error typically arises from hard dependencies. If you encounter persistent issues, checking whether the dependency is strictly necessary can help determine if the configuration should be adjusted or if the missing resource is genuinely critical.
Diagnostic Steps for Job Result Errors
To effectively debug these errors, you need to use
systemctl commands to inspect the status of both the failing service and its dependencies. Start by checking the detailed status of the affected service.
systemctl status runs-server.service
Look for lines indicating "Failed" or "Dependency failed." The output will often list the specific job that failed. Next, check the journal logs for more verbose details about why the dependency was not satisfied.
journalctl -xeu runs-server.service
The
-e flag shows the end of the log, which usually contains the most recent errors. Look for messages related to network timeouts, disk mount failures, or other service crashes. If the dependency is another service, check that service's status individually.
systemctl status [dependency-service-name]
If the dependency service is masked or disabled, ensure it is enabled and started. In some cases, the dependency might be waiting for a condition that never triggers, such as a specific device node appearing.
Common Causes and Solutions
There are several common scenarios that lead to dependency failures. One frequent cause is network-related issues. If your server relies on DNS resolution or a remote database, and the network interface is down or misconfigured, the service will fail. This is particularly relevant if you are running virtual machines or containers where network bridges might not be established immediately. For users encountering broader connectivity issues, reviewing guides on
Ubuntu 22.04 VM Internet Connection Issues can provide context on how network layer failures impact higher-level services.
Another common cause is timing issues. Some services start before their dependencies are fully initialized, especially during boot. Using
After= in the service file ensures ordering, but it does not guarantee readiness. You may need to add conditions like
ConditionPathExists= or use watchdog timers.
Storage dependencies are also frequent culprits. If a service requires a specific mount point that fails due to filesystem errors or incorrect
/etc/fstab entries, the service will fail. Check
dmesg for disk errors and verify mount points manually.
Adjusting Service Configuration
If a dependency is non-critical, you can change the service file to use
Wants= instead of
Requires=. Edit the unit file located in
/etc/systemd/system/ or
/lib/systemd/system/. After making changes, reload the daemon.
sudo systemctl daemon-reload
sudo systemctl restart runs-server.service
However, modifying core dependencies should be done with caution. Ensure that the service can function correctly without the previously required resource.
Related Troubleshooting Context
Sometimes, dependency failures are symptoms of deeper system instability. For instance, if you recently changed hardware components like processors or GPUs, system freezes or driver mismatches can cause services to fail during initialization. Understanding these broader system states is essential. Refer to
Troubleshooting System Freezes after Changing Processors or GPUs to rule out hardware-induced service failures. Additionally, package updates can sometimes break dependencies if libraries are upgraded inconsistently. Checking for broken packages is a good preliminary step before diving deep into systemd configurations. See
Troubleshooting Linux Package Updates for guidance on resolving library conflicts.
Frequently Asked Questions
What does 'Dependency failed' mean exactly?
It means systemd could not satisfy a hard requirement defined in the service unit file, such as a needed network interface or another service. Consequently, the target service is blocked from starting to prevent runtime errors.
How do I find which specific dependency failed?
Use
systemctl status [service-name] to see the immediate failure, then run
journalctl -xeu [service-name] to read the detailed logs. Look for lines mentioning "Failed to start" followed by the name of the dependent unit.
Can I ignore dependency failures for non-critical services?
Yes, by changing
Requires= to
Wants= in the unit file, you make the dependency soft. This allows the service to start even if the dependency fails, though functionality may be limited. Always test carefully after making this change.
Why does my service fail only after a reboot?
Reboots reset all services to their initial state. Timing issues are common here, where one service starts before its dependency is ready. Ensure proper ordering with
After= and consider adding readiness checks or delays if necessary.
Should I disable the failing dependency to fix the issue?
No, disabling a required dependency will likely cause the service to fail again or behave unpredictably. Instead, fix the root cause of the dependency failure, such as restarting the missing service or correcting network configurations.