Network availability systemd dependency failure at boot

[Sam Varshavchik]

Ed Greshko writes:

> On 07/06/14 07:28, Sam Varshavchik wrote:
> > Ed Greshko writes:
> >
> >> > The server with dhcp, httpd, named, and privoxy does not have  
> NetworkManager installed. Both the WAN and the LAN ports are configured as  
> static IPs.
> >>
> >> You may want to try NetworkManager and wait-online.  WAN links can take  
> time to become active.
> >
> > NetworkManager does nothing for me, except to suck in another 16 packages  
> it depends on, that I don't need. The WAN link is a statically-routed IP  
> traffic. It's up as soon as the network interface brings up the link.
>
> Now that you re-read what you wrote I think misunderstood WAN to be a  
> wireless connection which would require a time to bring up the link with the  
> AP.  If you mean WAN in the sense of a Wide Area Network, I wonder if there  
> is a need for PPP negotiation.

I didn't say PPP either. My WAN is not some screwed up pseudo-Internet  
connection that uses ppp over some godforsaken transport.

It is really a connection directly to the intertubes. As in: it swallows IP  
packets. The ISP on the other side sends packets to my IP addresses to my  
link, and I get them.

/etc/sysconfig/ifcfg-wan0 is simply:

TYPE=Ethernet
BOOTPROTO=none
IPADDR=216.254.115.190
ONBOOT=yes

plus a few miscellaneous settings that are not relevant.

None of this needs NetworkManager. The link comes up immediately, as soon as  
the network port powers up.

Similarly, the LAN0 port also has a hardwired IP address on it, and dhcpd is  
supposed to sink its claws into it, and manage my LAN.

That's, pretty much, how servers talk to the intertubes from a data center.

And now, any plain, garden-variety server that's hooked up directly to the  
intertubes, and does NOT bind to a TCP or a UDP port using a wildcard IP is  
now going to roll the dice: heads, and systemd happens to be busy before it  
gets around to it, and the network ports manage to finish initializing  
before the server gets forked off; tails, and it's hopelessly fracked up,  
because systemd is now going to fork it off before the network port has  
finished initializing.

I don't see anything in /lib/systemd/system that directly executes  
/etc/rc.d/init.d/network. So, it appears that this is systemd internal  
magic – it forks off /etc/rc.d/init.d/network, and marks network.target as  
being reached without waiting for this initscript to terminate. You know: to  
make boot faster. What a great idea.

So, systemd now becomes very busy forking off dhcp, named, httpd, innd, and  
whatever else declares after=network.target, before /etc/rc.d/init.d/network  
finishes sifting /etc/sysconfig/network-scripts, and finishes bringing up  
all the network interfaces.

Hilarity ensues.

-------------- 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/ca745f6f/attachment.sig>