systemd Service Ordering: Why Your Database Starts Before the Network Is Actually Up

Here's something that bit me recently.

You write a service unit with After=network.target, thinking your database will wait for the network. It doesn't. network.target only means the network stack is up — not that an interface has an IP, not that DNS works, not that you can reach anything.

The trap

[Unit]
Description=My Database
After=network.target

Looks right. But network.target is passive — it's pulled in by things that provide network, not things that require a working connection. Your service starts, tries to bind to 0.0.0.0:5432, and if the interface hasn't come up yet (DHCP, WiFi, VPN, whatever), it binds to nothing useful or fails silently.

The fix

[Unit]
Description=My Database
After=network-online.target
Wants=network-online.target

And enable the waiter:

systemctl enable systemd-networkd-wait-online.service

network-online.target is the one that actually waits for systemd-networkd (or NetworkManager, or whatever) to report "yeah, we're online." Wants= pulls it in so the target is active. After= orders after it.

The gotcha

If you're not using systemd-networkd — say you're on NetworkManager — you need:

systemctl enable NetworkManager-wait-online.service

Same idea. Different service name.

How to verify

systemctl show -p ActiveState network-online.target
# Should say 'active'

systemd-analyze plot > boot.svg
# Open it, find your service, see what it actually waited for

The plot doesn't lie. Your service bar should start after the network-online target bar ends.

---

Not a novel discovery. Just one of those things that's documented but easy to miss when you're in a hurry.