Dependencies & Ordering

systemd1-3 used After=network.target without fully explaining it. This chapter is the real depth — and the single most common point of confusion anyone new to systemd runs into.

Two Genuinely Separate Axes — What vs. When

The core confusion this chapter exists to resolve: "dependency" (should this unit even be started) and "ordering" (when, relative to another unit, should it start) are two separate, independently configured axes in systemd — not one combined concept, however natural that assumption feels at first. Wants=/Requires= control whether another unit gets started at all, as a side effect of this one starting. After=/Before= control only the order, with zero effect on whether anything actually gets started.

Wants= vs. Requires= — How Strict Is the Dependency?

Wants= is a soft dependency — if the wanted unit fails to start, the wanting unit still proceeds normally. The more common, more resilient choice for most real-world dependencies. Requires= is a hard dependency — if the required unit fails, systemd treats this unit's own startup as a failure too, and can stop it if the required unit later stops. Genuinely stricter, appropriate only when a unit truly cannot function at all without the other one.

A concrete example: a web server might Wants= a caching service — nice to have, but the site can still serve requests, just more slowly, if the cache is down — while it Requires= its own database, since it genuinely cannot function at all without one.

After= vs. Before= — Ordering Only, No Dependency Implied

This directly resolves systemd1-3's own After=network.target: it only says "if network.target is going to start anyway, for whatever reason, start after it." It does not, by itself, cause network.target to be started as a side effect. A unit with only After= and no Wants=/Requires= for the same target could, in principle, start with no network at all, if nothing else on the system independently wanted networking. This is exactly why real unit files commonly pair both together.

A Concrete Worked Example

In the second, broken version, if nothing else on the system happens to Want= network-online.target independently, this unit could start immediately — network or no network — with no error, no warning, just silently wrong behavior on a system where networking happens to come up slowly or not at all.

Target Units as Synchronization Points

systemd1-1 previewed target units replacing runlevels; systemd1-5 covers them in full. A target unit doesn't "do" anything itself — it's purely a named synchronization point, a milestone other units can Want=/Require=/order themselves around. This lets many otherwise-unrelated units all agree on "wait until networking is genuinely usable" without each one needing its own bespoke detection logic.

Viewing the Real Dependency Tree

Shows the actual, resolved dependency tree for a real unit on a real system — a genuinely concrete way to see this chapter's abstract material in practice, rather than only reasoning about it on paper.

Hands-On Exercises