A systemd service unit declares Requires=postgresql.service but has no After= line. Why can it still start before PostgreSQL is up, and what does After= actually change?

## Why the axes are separate at all systemd's design goal was to stop booting like a shell script. SysV-style init ran units in a serialised, numbered order; systemd builds a dependency graph and dispatches every job whose prerequisites are satisfied, all at once. To do that it needs to know two different things about a pair of units, and it refuses to guess one from the other: - **Requirement** — must the other unit be here, and what do I do if it is not? (`Wants=`, `Requires=`, `BindsTo=`, `Requisite=`, `PartOf=`, `Conflicts=`) - **Ordering** — is it allowed to run at the same time as me? (`After=`, `Before=`, and nothing else) If `Requires=` implied `After=`, every requirement would serialise the boot, and the parallelism that makes systemd fast would evaporate. So the split is a deliberate feature, not an oversight, and the price is that you have to write both lines. ## What actually happens with only Requires= ```ini [Unit] Description=Orders API Requires=postgresql.service [Service] ExecStart=/usr/local/bin/orders-api ``` systemd builds a transaction containing a start job for `orders-api.service` and a start job for `postgresql.service`. Nothing orders them, so both are dispatched immediately. In practice the small Go binary wins nine times out of ten and dies on connection refused; on a fast machine, or after a page cache warm-up, PostgreSQL sometimes wins and the bug "disappears". That intermittency is the signature of a missing ordering directive. There is a second, subtler consequence. The documented rule is that a failing required unit prevents your unit from starting **only when an `After=` ordering on it is also set**. Without the ordering there is no point in the timeline at which systemd can apply the rule — your job may already have run. So omitting `After=` does not merely lose the wait; it partially disarms `Requires=` itself. ## What After= does, precisely ```ini [Unit] Requires=postgresql.service After=postgresql.service ``` Now your start job is held until PostgreSQL's start job has completed. Three properties are worth stating exactly: 1. **It is pure ordering.** `After=` on its own never causes the other unit to be started. If `postgresql.service` is not part of the transaction — not enabled, not pulled in by anything — the ordering is simply ignored and your unit starts normally. 2. **`Before=` is the mirror image.** `A: After=B` and `B: Before=A` express exactly the same edge. Use `Before=` when you own the earlier unit and cannot edit the later one, typically via a drop-in. 3. **It is reversed at shutdown.** If A is `After=B` at start, then at stop A is stopped *before* B. You get correct teardown ordering for free, which matters when your service needs the database still alive to flush. ## The implicit ordering you already have With `DefaultDependencies=yes`, an ordinary service already carries `After=sysinit.target basic.target` and `Before=shutdown.target`. That is why you never write ordering against filesystem mounts or the early-boot machinery — it is already there. Units that must run earlier than `basic.target` have to set `DefaultDependencies=no` and then state every ordering edge by hand, which is where early-boot units get delicate. ## Reading the effective order on a live host ```bash systemctl list-dependencies --after orders-api.service systemctl list-dependencies --before orders-api.service systemctl show -p After -p Before -p Requires orders-api.service systemd-analyze verify /etc/systemd/system/orders-api.service ``` The `--after`/`--before` forms of `list-dependencies` show the ordering graph rather than the requirement graph, which is exactly the distinction under discussion. `systemd-analyze verify` loads the unit and reports syntax problems and references to units that do not exist — a cheap way to catch a typo like `After=postgres.service` on a host where the unit is actually called `postgresql.service`. A misspelt name in `After=` fails silently, because ordering against a unit not in the transaction is a legal no-op. ## Ordering targets rather than units When the thing you depend on is a class of service rather than a named one, order against a target: `After=network.target`, `After=nss-lookup.target`, `After=time-sync.target`. These are synchronisation points that other units declare themselves `Before=`, so you get a stable edge without hard-coding an implementation. The trade-off is that a target only means whatever its members agree it means, which is why some of them promise much less than their names suggest. ## The rule to leave the interview with Write the requirement and the ordering as a pair, on adjacent lines, every time. `Wants=` + `After=` for an optional dependency, `Requires=` + `After=` for a hard one. A requirement without an ordering is the classic systemd bug: it works on your laptop, fails on the slow VM, and fails differently after every reboot.