Targets, dependencies, and ordering · Linux

systemd does not start services one at a time. On every state change — boot, runlevel change, manual systemctl start — it computes a transaction: a list of jobs that bring the system to the desired state.

How systemd computes the transaction

flowchart LR
  STATE["Current state"]
  TARGET["Desired state"]
  GRAPH["Dependency graph"]
  TX["Transaction<br/>(ordered jobs)"]
  APPLY["Apply jobs"]

  STATE --> GRAPH
  TARGET --> GRAPH
  GRAPH --> TX
  TX --> APPLY

For each unit, systemd asks:

Is this unit supposed to be active in the desired state?
Is it currently active?
Does the dependency graph allow activation?

If yes to 1 and 3 and no to 2, the unit is queued for start. If yes to 1 but the dependency graph says a required unit is inactive, the start is deferred until the dependency is active.

Requires, Wants, Requisite, BindsTo

Directive	On start	On stop
`Requires=`	Start together; if dependency fails, this unit fails	Stop together
`Wants=`	Soft preference; ignore failure of dependency	(no effect)
`Requisite=`	Like Requires, but dependency must already be active when this unit starts	(no effect)
`BindsTo=`	Like Requires, but stronger — if dependency is stopped, this unit is also stopped	Always stopped together
`PartOf=`	(no effect on start)	When the LISTED unit is stopped or restarted, this unit is stopped/restarted too. One-way: changes to this unit do not affect the listed unit

PartOf= propagates downwards, not upwards

Read PartOf= as “this unit is part of that one”. Put PartOf=myapp.target in worker-1.service and the propagation runs from the target to the worker:

systemctl stop myapp.target stops worker-1.service too.
systemctl restart myapp.target restarts it too.
systemctl restart worker-1.service does nothing to the target or to the other workers.

The reverse reading — “restarting this unit restarts the listed one” — is wrong, and it fails in both directions at once: the team that restarts one worker expecting to cycle the group cycles nothing, and the team that stops the target believing the workers are unaffected stops every worker. man 5 systemd.unit puts it plainly: “When systemd stops or restarts the units listed here, the action is propagated to this unit.”

Verify the direction instead of trusting memory:

systemctl list-dependencies --reverse myapp.target
systemctl show worker-1.service -p PartOf -p ConsistsOf

ConsistsOf= is the inverse systemd creates automatically on the target. It cannot be set by hand; seeing it there confirms the PartOf= was written on the correct side.

Read-only / Safedependency types— sshd uses Wants+After for network-online.target — soft preference with ordering. nginx typically uses Requires for its configuration mount. The choice signals intent: Wants for 'should also be up'; Requires for 'cannot function without'.

$ grep -E '^(Requires|Wants|Requisite|BindsTo|PartOf)' /usr/lib/systemd/system/nginx.service /usr/lib/systemd/system/sshd.service 2>/dev/null

/usr/lib/systemd/system/sshd.service:Wants=network-online.target
/usr/lib/systemd/system/sshd.service:After=network-online.target

Illustrative output

After and Before — ordering, not dependency

After= and Before= are NOT dependencies. They are ordering constraints: “this unit starts AFTER the named unit”, or “this unit starts BEFORE the named unit”. The named unit is not pulled in if it is not already wanted by something else.

[Unit]
After=network-online.target
Wants=network-online.target

This pair is common: “after” for ordering, “wants” to pull in the dependency. Either alone is incomplete:

After= alone: ordering only — if network-online.target is not already going to start, sshd may start before the network.
Wants= alone: dependency without ordering — sshd may race the network.

Common bug: After= without Wants=

After= on its own creates ordering with no dependency. It says “if that unit is going to start, start after it” — and says nothing about whether it starts at all. So on a boot where nothing else pulls in network-online.target, the ordering constraint is vacuously satisfied and your service starts with no network.

The failure is intermittent by nature, which is what makes it expensive: on most boots something else does pull the target in, and the bug surfaces on the one host, or the one reboot, where nothing does.

Write both:

[Unit]
After=network-online.target
Wants=network-online.target

sshd gets this right — the output above shows both directives in the shipped unit, which is why it is worth reading as the reference example rather than as a bug. Check any unit you are unsure about with the merged view rather than the file on disk:

systemctl show -p After -p Wants sshd.service

One caveat on network-online.target itself: it is only meaningful if a wait service is enabled to define “online” — systemd-networkd-wait-online, NetworkManager-wait-online or equivalent. With none enabled the target completes immediately and the ordering buys you nothing.

systemctl is-enabled systemd-networkd-wait-online.service \
                     NetworkManager-wait-online.service 2>/dev/null

Reading the actual order

Read-only / Safesystemd-analyze— systemd-analyze dot produces a Graphviz dot file showing the dependency graph — useful in a debugging session. systemd-analyze without arguments shows boot timing. The 'graphical.target reached after N seconds' line tells you where time went during boot.

$ systemd-analyze dot sshd.service 2>/dev/null | head -20; systemd-analyze

Bootup finished in 4.234s (kernel) + 12.345s (userspace) = 16.579s
graphical.target reached after 12.001s in userspace

Illustrative output

Conflicts

Conflicts= means two units cannot be active at the same time. Starting one stops the other. Used for exclusive resources:

[Unit]
Conflicts=umount.target

Conflicts produces interesting behaviour: if unit A is running and you systemctl start B, systemd stops A and starts B. Useful when services claim exclusive resources (a network interface, a serial port).

Targets

Targets group units for collective state changes. Boot into multi-user.target means “every unit that multi-user.target Wants or Requires must be active”. Targets themselves do nothing — they are just collection points.

Read-only / Safemulti-user.target deps— multi-user.target pulls in every service tagged WantedBy=multi-user.target. Boot into multi-user.target means every service in this list (and its transitive deps) must be active.

$ systemctl list-dependencies multi-user.target | head

multi-user.target
● ├─accounts-daemon.service
● ├─chrony.service
● ├─cron.service
● ├─dbus.service
● ├─getty.target
● ├─nginx.service
● ├─sshd.service
● └─systemd-update-utmp.service
...

Illustrative output

Common dependency bugs

My service starts before its dependency: missing After=.
My service starts but the dependency does not: missing Wants= or Requires=.
My service refuses to start: required dependency is in failed state; fix the dependency first.
Cycle detected: two units depend on each other. systemd refuses to start either until the cycle is broken.

Read-only / Safefailed state— Active: failed means the service tried to start, exited with non-zero status, and systemd has given up. Read the journal (journalctl -xeu myapp) for the failure cause. Result: start-limit-hit means Restart=on-failure triggered too many times within StartLimitIntervalSec.

$ systemctl status myapp 2>&1 | head -10

● myapp.service - MyApp daemon
Loaded: loaded (/etc/systemd/system/myapp.service; enabled; vendor preset: disabled)
Active: failed (Result: start-limit-hit) since ...
Main PID: 12345 (code=exited, status=2)
...

Illustrative output

How systemd computes the transaction

Requires, Wants, Requisite, BindsTo

After and Before — ordering, not dependency

Reading the actual order

Conflicts

Targets

Common dependency bugs

Knowledge check