dhcpd and systemd

[Sam Varshavchik]

Ian Chapman writes:

> On 17/07/14 18:57, Sam Varshavchik wrote:
>
>>> Dhcpd on my server has suddenly started taking to start before the IP
>>> address (statically assigned) has been configured on the network
>>> interface and consequently bombs out. The systemd service for dhcpd has
>>>
>>> After=network.target
>>>
>>>
>>> should this be network-online.target?
>>
>> Won't make a difference.
>>
>> Welcome to the systemd fan club.
>>
>> Install the following file as /etc/systemd/system/wait-for-network.service
>
> Thanks Sam, actually it did seem to work fine for me. I changed it to  
> network-online.target and dhcpd did start on boot.

It'll work for a while. At some point, it's going to break again (the next  
systemd update, likely).

>                                                     I'm using the traditional  
> 'network' service rather than NetworkManager because at the time  
> NetworkManager didn't support bridges, so I'm not sure if that differs from  
> your setup.

No, that's my setup.

The stub service is the only reliable, permanent fix to this systemd brain  
damage.

The only reason your change "worked" is because it altered, slightly, how  
systemd chooses, more or less, at random, the order in which to fork off  
services it thinks should be started at the same time; in combination with  
the time it takes each individual service to start.

Despite the outward appearance, systemd is completely ignoring all Before  
and After directives. Only now, the combination you have, is working solely  
due to chance. At some point, an update to some other unrelated package  
might change its startup profile sufficiently to collapse the entire house  
of cards, and make everything break again.

Been there, done that, have the souvenirs on my fireplace mantle.

>             I did however have to jump through similar hoops with autofs  
> though on my client, eventually making the display manager depend on  
> NetworkManager-wait-online.service because it was possible to login before  
> autofs even started. It seems that Bind might have issues along similar  
> lines to dhcpd too, except that it does start but refused to serve DNS  
> requests until I restart the service.

That's because at the time it starts, not all network interfaces are set up,  
so it only binds itself to localhost. You can determine it by sifting  
through the syslog, looking at what bind is doing at startup.

In my case, all network servers were frakked up. dhcp. bind. httpd. privoxy.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.fedoraproject.org/pipermail/users/attachments/20140717/6cc53dcd/attachment.sig>