On systemd network configuration dependencies
It is very easy to affect systemd’s unit ordering. On the other hand you need to be careful about what a completed unit guarantees.
Configure your service
On current systems,
network.target just guarantees that the network service has been started, not that there’s some actual configuration. You need to order after
network-online.target and pull it in to achieve that.
[Unit] Wants=network-online.target After=network-online.target
For compatibility with older systems, you may need to order after network.target as well.
[Unit] Wants=network-online.target After=network.target network-online.target
That’s for the unit file of your service and for systemd.
Implementation in current versions of software
Now you need to make sure that
network-online.target works as expected (or that you at least can use
The current version of NetworkManager offers the
NetworkManager-wait-online.service which gets pulled in by
network-online.target and thus by your service. This special service ensures that your service will wait until all connections configured to be started automatically succeed, fail, or time out.
The current version of systemd-networkd blocks your service until all devices are configured as requested. It is easier in that it currently only supports configurations that are applied at boot time (more specifically the startup time of `systemd-networkd.service).
For the sake of completeness, the
/etc/init.d/network service in Fedora, as interpreted by the current versions of systemd, blocks
network.target and thus indirectly blocks
network-online.target and your service. It’s an example of a script based implementation.
If your implementation, whether daemon based or script based, behaves as one of the network management services above, it will delay the start of your service until network configuration is either successfully completed, failed for a good reason, or timed out after a reasonable time frame to complete.
You may want to check whether netctl works the same way and that information would be a valuable addition to this answer.
Implementations in older versions of software
I don’t think you will see a sufficiently old version of systemd where this wouldn’t work well. But you can check that at least
network-online.target exists and that it gets ordered after
Previously NetworkManager only guaranteed that at least one connection would get applied. And even for that to work, you would have to enable the
NetworkManager-wait-online.service explicitly. This has been long fixed in Fedora but was only recently applied upstream.
systemctl enable NetworkManager-wait-online.service
Notes on network.target and network-online.target implementations
You shouldn’t ever need to make your software depend on
NetworkManager-wait-online.service nor any other specific services. Instead, all network management services should order themselves before
network.target and optionally
A simple script based network management service should finish network configuration before exiting and should order itself before
network.target and thus indirectly before
[Unit] Before=network.target [Service] Type=oneshot ExecStart=... RemainAfterExit=yes
A daemon based network management service should also order itself before
network.target even though it’s not very useful.
[Unit] Before=network.target [Service] Type=simple ExecStart=...
A service that waits for the daemon to finish should order itself after the specific service and before
network-online.target. It should use
Requisite on the daemon service so that it fails immediately if the respective network management service isn’t being used.
[Unit] Requisite=... After=... Before=network-online.target [Service] Type=oneshot ExecStart=... RemainAfterExit=yes
The package should install a symlink to the waiting service in the
wants directory for
network-online.target so that it gets pulled in by services that want to wait for configured network.
ln -s /usr/lib/systemd/system/... /usr/lib/systemd/system/network-online.target.wants/
I hope I not only helped to answer your question at the time you asked it, but also contributed to improving the situation in upstream and Linux distributions, so that I can now give a better answer than was possible at the time of writing the original one.
You can use
[Unit] section to define a service that should be started before your service starts. For example if you are using NetworkManager, you can make your service start after NetworkManager is started.
[Unit] Description=test service After=NetworkManager.service
If your service provides a server, which can wait passively for someone to connect to it, use this:
Your service should bind on the wildcard interface. If it uses socket activation (recommended), or if it is local-only, you can ignore network targets entirely.
If your service acts as a client, or is peer to peer, this is more appropriate:
[Unit] After=network-online.target Requires=network-online.target
Prior to systemd 213, network-online.target needs the workaround Pavel mentioned (you need to manually enable a service that will wait for the network to be up). As of systemd 213 this is done by default.
systemd-networkd-wait-online will wait for at least one address (either routable or link-local) to be configured on a non-loopback interface.
Configuring systemd-networkd, NetworkManager or equivalent is an independent task. DHCP (for IPv4) and NDP (for IPv6) tend to work out of the box, but you should configure them so that your precise definition of “the network is up” is what triggers
- Running Services After the Network is up