Dependencies and ordering

Dependency directives (Wants, Requires) answer “does this unit need to be active?” Ordering directives (After, Before) answer “which unit starts first?” They are completely orthogonal.

You can have ordering without dependency: After=network.target means “start after the network target has been reached” but if the network target fails, your service still tries to start. You can have dependency without ordering: Requires=postgresql.service means “if postgres is not active, fail” but without After=postgres.service systemd may try to start both at the same time (parallel activation).

In practice you almost always want both:

[Unit]
# Dependency: if postgres is not running, this service cannot function
Requires=postgresql.service
# Ordering: start this service AFTER postgres has activated
After=postgresql.service

Omitting After= with Requires= is the race condition that bites most people: both services start in parallel, your service connects before postgres is listening, and it fails — even though technically the dependency is declared.

Wants= vs Requires= is about failure tolerance. This is the most important distinction in the dependency system:

Wants= is the right choice for optional dependencies — a metrics exporter that works better with Redis but degrades gracefully without it. Requires= is for hard dependencies — a service that cannot function at all without the database. BindsTo= is for tightly coupled pairs like a service and its companion network namespace unit.

[Unit]
# Soft dependency: try to start redis, but proceed even if it fails
Wants=redis.service
After=redis.service

# Hard dependency: if postgres fails, stop this service too
Requires=postgresql.service
After=postgresql.service

After= and Before= control ordering within a parallel activation. systemd’s default is to start units in parallel — the dependency graph fans out and everything whose deps are satisfied starts simultaneously. After= inserts a sequencing constraint:

[Unit]
# Do not start until network-online.target is reached
After=network-online.target
# Ensure this service stops before the network goes down (on shutdown)
Before=network.target

network.target vs network-online.target is a common pitfall: network.target is reached when the network interfaces are up, which happens almost immediately. network-online.target is reached when the network is routable — DNS resolves, default route exists. A service that makes outbound connections needs After=network-online.target, not After=network.target.

# See what network-online.target actually depends on
systemctl list-dependencies network-online.target

WantedBy= in [Install] is what systemctl enable acts on. It does not create a dependency from your service to the target — it creates one in the other direction: when systemctl enable myapp.service is run, it creates a symlink at /etc/systemd/system/multi-user.target.wants/myapp.service. When systemd activates multi-user.target at boot, it reads that wants/ directory and starts everything in it.

[Install]
WantedBy=multi-user.target

This is why the [Install] section has no effect until you run systemctl enable. The section describes how to install the unit, not a live dependency. multi-user.target is the right choice for any service that should run in a normal (non-graphical, networked) system. For services that only make sense with a GUI, use graphical.target.

# See what multi-user.target will start (after enabling your service)
ls /etc/systemd/system/multi-user.target.wants/

How a target pulls in its dependencies — and why this matters for your own targets. A target is just a named synchronisation point. When systemd activates multi-user.target, it:

1. Reads its Wants= and Requires= directives (static, in the unit file)
2. Reads its wants/ and requires/ drop-in directories (dynamic, populated by systemctl enable)
3. Starts all units found by steps 1 and 2, honouring their After= constraints

# See the full dependency tree for multi-user.target
systemctl list-dependencies multi-user.target

# See only the units directly wanted by the target
systemctl list-dependencies --plain multi-user.target | head -20

Understanding this chain — target → wants dir → your service — is what makes systemctl enable feel less like magic. Enable just drops a symlink into a directory that systemd already reads.