Network availability systemd dependency failure at boot

[Sam Varshavchik]

It looks like after the last systemd update, systemd appears to start jobs  
that have a dependency on network availability before the network is  
actually up.

After booting, a crapload of services reliably fail to start: httpd, dhcpd,  
named, and others. All of them come up fine if I manually start them, after  
boot completes.

Sifting through /var/log/messages, the common thread is that the network is  
NOT up, when the jobs start:

Jul  5 07:16:41 shorty httpd: (99)Cannot assign requested address: AH00072:  
make_sock: could not bind to address 216.27.136.223:8443
Jul  5 07:16:41 shorty httpd: no listening sockets available, shutting down
Jul  5 07:16:41 shorty httpd: AH00015: Unable to open logs

And:

Jul  5 07:16:40 shorty dhcpd:
Jul  5 07:16:40 shorty dhcpd: No subnet declaration for lan0 (no IPv4  
addresses).
Jul  5 07:16:40 shorty dhcpd: ** Ignoring requests on lan0.  If this is not  
what
Jul  5 07:16:40 shorty dhcpd: you want, please write a subnet declaration
Jul  5 07:16:40 shorty dhcpd: in your dhcpd.conf file for the network segment
Jul  5 07:16:40 shorty dhcpd: to which interface lan0 is attached. **
Jul  5 07:16:40 shorty dhcpd:
Jul  5 07:16:40 shorty dhcpd:
Jul  5 07:16:40 shorty dhcpd: Not configured to listen on any interfaces!

Here's bind shutting down before the server reboot:

Jul  5 07:14:30 shorty named[1072]: no longer listening on 127.0.0.1#53
Jul  5 07:14:30 shorty named[1072]: no longer listening on 192.168.0.1#53
Jul  5 07:14:30 shorty named[1072]: no longer listening on 216.254.115.190#53

Note all the IP addresses that my bind is listening on. Now, here's bind  
again, when the system comes up after a reboot:

Jul  5 07:16:39 shorty named[1071]: loading configuration from  
'/etc/named.conf'
Jul  5 07:16:39 shorty named[1071]: using default UDP/IPv4 port range:  
[1024, 65535]
Jul  5 07:16:39 shorty named[1071]: using default UDP/IPv6 port range:  
[1024, 65535]
Jul  5 07:16:39 shorty named[1071]: listening on IPv4 interface lo,  
127.0.0.1#53
Jul  5 07:16:39 shorty named[1071]: generating session key for dynamic DNS
…

That's it. Only 127.0.0.1 was up for bind to listen on. Even lan0,  
192.168.0.1, isn't up yet.

Sifting through systemd docs, it appears that services that require network  
availability should state an After dependency on "network-online.target".  
Wonderful. Can someone explain why, if that's true, only kdump.service  
appears to explicitly state that dependency?

[root at shorty system]# fgrep -- network-online.target *.target
[root at shorty system]# fgrep -- network-online.target *.service
kdump.service:After=network.target network-online.target remote-fs.target

So, I see two possible explanations:

1) network-online.target was introduced in the most recent systemd update.  
Prior to that, its equivalent functionality was done in some other way,  
possibly integrated with network.target. The last update unceremoniously  
introduced network-online.target, with no advance notice, and without any  
coordination with packages that need to use it, and thus breaking everything.

2) everything was always like that. Everything was always broken, but until  
the recent systemd update, its internal logic happened to kick things off in  
the right order. The last update changed some internal scheduling logic, and  
now everything is broken.

So, how should this mess get fixed? Start filing bugs against all these  
packages, requesting a change to their systemd service file, to state a  
dependency on network-online.target?

-------------- 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/20140705/150fa096/attachment.sig>