Service Dependencies

Service dependencies in systemd control two independent things: ordering (which unit starts first) and requirements (whether a unit must succeed for another to start). These are separate concepts and must be understood independently. A common mistake is thinking After= implies a requirement relationship — it does not. After= only says "if we both start, I start after you."

Why dependencies matter at boot

Without dependencies:
  systemd starts everything in parallel → mysql starts before disk is mounted
  → mysql cannot find data directory → mysql fails → web app fails

With dependencies:
  mysql.service: After=local-fs.target Requires=local-fs.target
  → systemd mounts filesystems first
  → then starts mysql
  → then starts web app

Ordering directives: After and Before

# After=: "I should start AFTER these units have activated"
# Does NOT mean the listed units are required — if they are not running, this unit still starts

[Unit]
After=network.target mysql.service

# Before=: "I should start BEFORE these units"
# Reverse of After=
# Example: use Before= in a unit that sets up a prerequisite
[Unit]
Before=mysql.service    # "Start me before mysql"

Requirement directives

DirectiveEffect
Requires=Hard dependency: if listed unit fails to start, this unit also fails. If listed unit stops, this unit stops.
Wants=Soft dependency: systemd will TRY to start the listed unit, but if it fails, this unit still starts.
BindsTo=Stronger than Requires: if listed unit stops for ANY reason, this unit stops immediately.
PartOf=Restart/stop is propagated from listed unit to this one, but not vice versa.
Conflicts=This unit cannot run at the same time as the listed unit.
# Example: web app that requires mysql, should start after network
[Unit]
Description=My Web Application
After=network.target mysql.service
Requires=mysql.service    # If mysql is not running, don't start us

# Example: service that should NOT run at same time as another
[Unit]
Conflicts=apache2.service    # Cannot coexist with apache2

Viewing the dependency tree

# Show what units a service depends on (direct + transitive)
systemctl list-dependencies nginx.service

# Show what depends ON a service (reverse)
systemctl list-dependencies --reverse nginx.service

# Check ordering relationships specifically
systemctl list-dependencies --before nginx.service
systemctl list-dependencies --after nginx.service

# View all dependency info for a specific unit
systemctl show mysql.service -p Requires,Wants,After,Before

list-dependencies output

nginx.service
● ├─system.slice
● ├─sysinit.target
● │ ├─apparmor.service
● │ ├─dev-hugepages.mount
● │ └─... (transitive deps)
● └─network.target
    └─network-online.target

Common dependency patterns

# Pattern 1: Web app that needs database
[Unit]
Description=Web Application
After=network.target postgresql.service
Requires=postgresql.service

# Pattern 2: Service that needs network to be fully up (not just online)
[Unit]
After=network-online.target
Wants=network-online.target

# Pattern 3: Multiple services in a stack (docker compose alternative)
# redis.service
[Unit]
After=network.target

# api.service
[Unit]
After=network.target redis.service
Requires=redis.service

# nginx.service (included by apt) automatically Wants multi-user.target

# Check that your dependency declarations are correct
systemd-analyze verify /etc/systemd/system/myapp.service

Conclusion

After= and Before= control only startup ordering. Requires= and Wants= control whether a dependency must succeed. Most custom services need both: After=mysql.service to start in the right order AND Requires=mysql.service so that the web app does not start without its database. Use Wants= instead of Requires= for optional dependencies where degraded operation is acceptable. Use systemctl list-dependencies --reverse servicename to understand what stops if your service stops.

FAQ

Is Service Dependencies important for Ubuntu administrators?+

Yes. It supports practical Ubuntu administration because it connects directly to server reliability, security, troubleshooting, or daily operations.

Should I practice this on a live server?+

Use a lab VM first. After you understand the command output and rollback path, apply the workflow carefully on real systems.

What should I do after reading this article?+

Run the practice commands, write down what each one shows, and continue to the next article in the Ubuntu roadmap.

Need help with Ubuntu administration?

Work directly with Muhammad Irfan Aslam for Ubuntu Server, Linux, cloud, Docker, DevOps, CI/CD, or infrastructure troubleshooting support.

Hire Me for Support