How to force network.target to wait for DHCP with systemd-networkd?

Question

I'm using systemd-networkd to configure my interfaces:

[Match]
Name=enp3s0

[Network]
DHCP=v4    

It works quite well except that at boot, some services are not waiting for DHCP to finish. For instances my NFS-mounted directories and nginx fail because there is no network at the time they boot.

Is there a way to force network.target to wait for DHCP?

---

Note from the editor. According to the documentation:

Many network management solutions provide a way to unconditionally pull in network-online.target, and thus upgrading the effect of network.target to the effect of network-online.target.

If you use systemd-networkd you can do this by enabling systemd-networkd-wait-online.service:

systemctl enable systemd-networkd-wait-online.service

However I tried this and it did not make services depending on network.target wait for DHCP. It only made services which explicitly depend on network-online.target wait for DHCP, and in fact it is required to make that work.

Solution 1

When using systemd-networkd, to make sure that all interfaces are up and have an IP address assigned use:

systemctl enable systemd-networkd-wait-online.service

Someone else may be using NetworkManager, in which case that would be:

systemctl enable NetworkManager-wait-online.service

See: http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/

Solution 2

Most linux variants use Network Manager with systemd using NetworkManager-wait-online.service to determine whether or not the network is up. If this is the case, you can edit /lib/systemd/system/NetworkManager-wait-online.service and change:

ExecStart=/usr/bin/nm-online -s -q --timeout=30

To:

ExecStart=/usr/bin/nm-online -q --timeout=30

The -s option means: Wait for NetworkManager startup to complete, rather than waiting for network connectivity specifically.

Removing it will give a better indication of the network status and systemd can wait for it to come up before starting the dependant services.

Comments

[Admin]

The other services should be waiting for the network, with {After,Wants}=network-online.target.

[Admin]

@jasonwryan I can edit my own services, but what about NFS mount for instance ? There is no service file for that. Or sshd.service, should I edit all of them ? Isn't there any way to force network.target = network-online.target ?

[Admin]

Do you need to wait for DHCP? Can you assign a static IP?

[Admin]

Yes, I need to wait. I switched from static IP to DHCP and that's caused all the problems. No, I do not want to assign static IPs.

[Admin]

I'm also having this problem. I have {After,Wants}=network-online.target in my service unit, and systemd-networkd-wait-online.service is enabled. Still, my service immediately starts after the links is activated, but without having an ipv4 address via DHCP.

[TCB13]

I did this, still no luck...

[ernesto che]

Maybe it's because the interface also has an IPv6 address, and systemd-neworkd-wait-online thinks that's enough: lists.freedesktop.org/archives/systemd-devel/2016-July/…

[collegian]

This doesn't address the question at all. Also you just created a circular dependency where the thing that brings up network interfaces won't run until the network interfaces are up.

[Centimane]

@ali1234 "Is there a way to force systemd-networkd to wait for DHCP or another target to wait for in the other service files" The systemd service file is what determines when the service is started, so I wouldn't say it "doesn't address the question at all". I'll concede that network-online.target is not the unit needed here, but the rest of the answer is still valid. I'll take out the network-online.target mention though and look into the dhcpclient a little more. Seems like the network-functions normally call /sbin/dhcpclient which systemd-networkd is probably also doing.

[collegian]

The person who originally asked this question phrased it very badly. They actually want to make network.target wait until an interface has been assigned an address on DHCP. According to the documentation linked in the other answer 'systemctl enable systemd-networkd-wait-online.service' does that. But in reality it does not.

[Centimane]

@ali1234 A bit of a hack way to achieve this would be a new systemd service that is before systemd-networkd, with an ExecPre calling a script that loops trying to call dhcpclient on the first interface until it suceeds. Even if the first interface isn't DHCP it'll get overwritten when systemd-network does start. This assumes systemd-networkd is mostly just responsible for configuring the interfaces.

[collegian]

systemd-networkd does all interface management from bringing up the interfaces to doing DHCP so that would still cause a circular dependency.

[Centimane]

@ali1234 If systemd-networkd is responsible for enabling DHCP, and DHCP isn't ready by the time it's trying to enable the interfaces I would say that's a bug in systemd-networkd and should probably be raised to their site.

[collegian]

DHCP fetches an IP address from the network, therefore it CANNOT work until the network interfaces are up. systemd-networkd brings the network interfaces up. Therefore if you force systemd-networkd to wait until DHCP has been performed, you have created a circular dependency. This is not a bug, it is a fundamental fact of how DHCP works.

[Centimane]

@ali1234 DHCP is a broadcast request, which the DHCP server responds via MAC address, the interfaces need to be functional, but the order of operations should be functional interfaces -> make DHCP requests -> config static addresses -> confirm DHCP requests/static sets are done

[collegian]

Exactly and systemd-networkd is responsible for the first item in your list, which is also called "bringing up interfaces" as it is what happens when you run "ifconfig eth0 up" (without supplying an IP address).

[Centimane]

@ali1234 I'm saying if systemd-networkd doesn't do all of these before continuing on, then that sounds like a bug in systemd-networkd (that it can be finished before it's DHCP interfaces are up at all)