Bug#806949: ifupdown: some tweaks to networking.service

[Guus Sliepen]

On Thu, Dec 10, 2015 at 01:59:42PM +0100, Michael Biebl wrote:

> > Now that we have a proper systemd service
> > for ifupdown, could we just add WantedBy=network-online.target to
> > networking.service? The only difference to me seems that your script
> > waits until ifup has configured at least one interface, while the simple
> > WantedBy line waits until all auto interfaces have been configured.
> 
> I think that my PoC waits for both types is an important difference.

That's true.

> Also, in general, I think it's better if we split the device activation
> and the "waiting for the network to be up" into separate services.
> 
> The benefit here is, that other services, that don't need
> network-online.target would not be blocked unnecessarily during boot.

I don't understand this. Are services that don't need
network-online.target blocked by networking.service in some way?

Anyway, if we are going for a script that polls stuff, then why not
decouple it completely from ifupdown or whatever networking framework is
used, and do the following?

#!/bin/sh
TIMEOUT=30

offline() {
	ip -4 r s | grep -q ^default && return 1
	ip -6 r s | grep -q ^default && return 1
	return 0
}

i=0
while offline; do
	if [ $i = $TIMEOUT ] ; then
		break
	fi
	i=$(($i+1))
	sleep 1
done

Which is just waiting until we have a default route. It can be made to
respond more quickly by using the "ip monitor" command. It's still not
perfect, but in general it's a better default criterion for being online
than "a network interface was configured". For example, the following
/e/n/i would cause your script to think the network is online:

iface foo inet manual

Or if you have a LAN and WAN interface, and the WAN interface is getting
a DHCP address which can take some time, and a LAN interface which is
configured statically, in which case some other service that waits for
network-online.target might start too early and only bind to the LAN
interface's address.

Of course, in the case of NFS mounts you typically do that over a LAN
and don't care about the WAN at that point (and maybe your server will
never get a default gateway route on purpose). In this case, you'd
actually want to wait until NFS server's IP address becomes routable,
and then start the mount command.

So network-online.target is very ill-defined, and I'd rather not see
anything depending on it, but if we have to, I'd like something that is
as conservative as possible.

-- 
Met vriendelijke groet / with kind regards,
      Guus Sliepen <guus at debian.org>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20151210/798424e6/attachment-0002.sig>