On current systems, ordering after 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 achive that.

For the sake of completeness, the /etc/init.d/network service in Fedora, as interpretted 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 deamon 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 shouldn't ever need to make your software depend on NetworkManager.service or NetworkManager-wait-online.service nor any other specific services. Instead all network management services should order themselves before network.target and optionally network-online.target.

A simple script based network management service should finish network configuration before exitting and should order itself before network.target and thus indirectly before network-online.target.

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.

On current systems, ordering after 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.

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 shouldn't ever need to make your software depend on NetworkManager.service or NetworkManager-wait-online.service nor any other specific services. Instead, all network management services should order themselves before network.target and optionally network-online.target.

A simple script based network management service should finish network configuration before exiting and should order itself before network.target and thus indirectly before network-online.target.

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.

For compatibility with older systems, you may need to order after network.target as well. Whether you pull it in should not typically make a difference.

[Unit]
Wants=network.target network-online.target
After=network.target 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

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. On current systems, NetworkManager.service, network.target and network-online.target by default only guarantee that NetworkManager has been started and it doesn't say anything about network configuration.

You need to enable NetworkManager-wait-online.service in order to make network.target and network-online.target wait for the first successful connection configured in NetworkManager. It's not perfect but it works, more or less.

For boot time ordering, I advise you to have the following in your unit:

[Unit]
Wants=network.target network-online.target
After=network.target network-online.target

You shouldn't need to add any Requires or Wants on NetworkManager-wait-online. Instead, the currently supported way is to just enable the wait online service:

systemctl enable NetworkManager-wait-online.service

A similar problem has been reported for the Fedora aiccu package:

• https://bugzilla.redhat.com/show_bug.cgi?id=844607

I recently started a bugzilla ticket for NetworkManager upstream:

• https://bugzilla.gnome.org/show_bug.cgi?id=728965

You may want to check whether netctl works the same way.

More resources:

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, ordering after 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 achive 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. Whether you pull it in should not typically make a difference.

[Unit]
Wants=network.target 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 network.target).

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 interpretted 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 deamon 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 network.target.

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.service or NetworkManager-wait-online.service nor any other specific services. Instead all network management services should order themselves before network.target and optionally network-online.target.

A simple script based network management service should finish network configuration before exitting and should order itself before network.target and thus indirectly before network-online.target.

[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/

Related documentation

Final notes

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.