A systemd service that needs a configured IP address at startup declares After=network.target, yet at boot it still fails with "cannot assign requested address". What does network.target actually guarantee, and what should the unit declare instead?

## Why network.target disappoints people The name reads like a promise about the network. It is not. `network.target` is a passive synchronisation point with two documented meanings, and neither is "you have an address": - **At boot**, units ordered `After=network.target` are started after the network management stack has been started. The manager is running; it has not necessarily finished doing anything. - **At shutdown**, the ordering is reversed, so `Before=network.target` on the teardown side is how a unit gets stopped while the network still exists. This is arguably the more important of the two uses, and it is why the target exists at all. So `After=network.target` on a service that binds to a specific address, or that dials out on startup, buys you very little. DHCP may not have returned, IPv6 may still be in duplicate-address detection, the interface may be enumerated but unconfigured. The failure is timing-dependent, which is why it shows up on one host in twenty and "goes away" when you add a sleep. ## network-online.target and the wait-online services `network-online.target` exists for the case where the unit genuinely cannot proceed without connectivity. It is also passive — it does nothing by itself. What gives it meaning is a *wait-online* service that is ordered before it and blocks until the network manager reports that configuration is done: - `systemd-networkd-wait-online.service` when the host uses systemd-networkd - `NetworkManager-wait-online.service` when the host uses NetworkManager Whichever is appropriate must be **enabled**. If neither is, `network-online.target` activates immediately and your ordering is decorative. Check it: ```bash systemctl is-enabled NetworkManager-wait-online.service systemctl status systemd-networkd-wait-online.service ``` ## The correct unit stanza ```ini [Unit] Description=Metrics shipper Wants=network-online.target After=network-online.target [Service] ExecStart=/usr/local/bin/shipper Restart=on-failure RestartSec=5s [Install] WantedBy=multi-user.target ``` Both lines matter, for different reasons. `After=` supplies the ordering. `Wants=` supplies the *pull* — ordering against a unit that is not in the transaction is a no-op, and nothing else on a typical host pulls `network-online.target` in. Writing only `After=network-online.target` is the single most common way to get this wrong while believing it is fixed. ## What "online" actually means Even with everything wired correctly, the guarantee is weaker than the name suggests. The wait-online implementations decide when *their* notion of configuration is complete — by default something like "all managed interfaces that are expected to come up have done so". They cannot know whether your VPN is established, whether the route to the specific peer you need exists, or whether DNS resolves. On a multi-homed host the interface that came up may not be the one you care about; `systemd-networkd-wait-online` accepts options to wait for particular interfaces, which is worth reaching for when the default is too loose. And none of it helps after boot. A DHCP lease change, a link flap or a firewall reload can drop connectivity at 3 a.m., long after any target has been reached. Boot ordering has nothing to say about that. ## The judgment an interviewer is listening for The strong answer has two halves: 1. **Order correctly** — `Wants=` plus `After=network-online.target`, with the wait-online service enabled, for units that genuinely cannot start without an address (a daemon that binds one specific IP, a mount of a remote filesystem, a one-shot registration). 2. **Prefer not to need it** — a long-running service should tolerate a network that is not there yet. Retrying with backoff, or letting `Restart=on-failure` with a sensible `RestartSec=` do the retrying, makes the service correct at boot *and* correct at 3 a.m., and it does not extend the boot by however long the wait-online service blocks. Every unit that waits for the target serialises part of the boot behind it, so adding it to everything is a real cost. That second half is what separates someone repeating a recipe from someone who has operated fleets: `network-online.target` is a crutch for software that cannot retry, and a lot of software can. ## Related synchronisation points `nss-lookup.target` is the ordering point for name resolution being available and is what a unit needing DNS at startup should order against. `network-pre.target` runs *before* the network comes up, which is where firewall rule loading belongs so that no packet is accepted before the policy exists. Like the others, these are passive: they mean whatever the units around them have agreed, so verify rather than assume.