Technical stuff from a bit-head

Articles, write-ups, etc.

Getting systemd services to wait for networking in Raspbian

by · March 15, 2018

For isc-dhcp-server:

I tried several things which did not work.  I concluded that this is primarily because isc-dhcp-server doesn’t use a true systemd script.  So I edited the sysV startup script (/etc/init.d/isc-dhcp-server) and inserted a loop that waits until the non-loopback IP is up.  The loop times out after 10 seconds.  At the beginning of the “start” section:

 _IP=$(hostname -I)
 retry_count=0
 while [ ! "$_IP" ] && [ $retry_count -lt 10 ]; do
   _IP=$(hostname -I)
   retry_count=$((retry_count+1))
   sleep 1
 done

This seems to work for DHCP.  It’s really a workaround, but it does the job.

Interestingly, nothing in /etc/rc3.d had a start priority greater than 4.  If you remember the old days, the really critical stuff was symlinked as “S00…” and poor rc.local, the last thing to run, was “S99rc.local”.  But now everything is S01 through S04.

The big takeaway for me is that everything runs so quickly that the DHCP server comes online before the IP is fully configured.  While I love quicker boot times, this part of systemd is frustrating.  And from all the posts I read, many others feel the same way.  Hooray progress!

For bind:

What did not work:

-I edited the systemd script and changed network.target to network-online.target for the Wants= and After= items.

-I also tried setting those to dhcpcd.service, to no avail.

-In /etc/dhcpcd.conf, under the section where I configure the static IP for eth0, I added “waitip 4” to force it to wait for the IP to come up before forking to the background.

 

A workaround that functioned:

In /etc/bind/named.conf.options I set interface-interval to 1 minute.  This is the option that tells named to re-scan for new network interfaces that fall within the limits of listen-on.  Setting it to 1 minute is fine, for the most part.  But frankly I want a solution that works right at boot (yeah, yeah, impatience).

What worked

I installed NetworkManager, which apparently adds “NetworkManager-wait-online.service” that actually works when you set “After=network-online.target”.

 

You may also like...