Hey guys... On Mon, 2014-11-10 at 04:08 +0100, Michael Biebl wrote: > > But you have seen what I've wrote previously,.. that I *do* in fact also > > have issues with allow-hotplug... so there most likely is something > > fishy there (or in unit files of services) as well.. > > So is this something that I should deal with in another bug? > > You are conflating two issues. > Bringing an interface up with ifup@.service is not racy, since it runs > when the hardware is actually added. *BUT* you lose the synchronisation > point that is /etc/init.d/networking, since ifup@.service can be > triggered at any time and doesn't delay boot. Well but then we must have some other issue, cause it can't be that services are started before networking is there.
Either that means that people should be advised *not* to use allow-hotplug, when they have services which only once statically bind to their addresses,... Or services would need to depends on network.target (which is kinda ugly IMHO)... which would need to be guaranteed to be only reached after the hotplugged interfaces came up as well. Apart from that, AFAIR, the services which didn't came up correctly with allow-hotplug were only such whose init-scripts were used in LSB-compat mode by systemd (sks, apache httpd don't seem to have native unit files). So is it assured, that their $network is the same then network.target? Cause then I wouldn't understand, why they couldn't bind. > SysV init script (or other services which depend on $network or > network.target) therefor have a problem with allow-hotplug. ah... here you say it... Shouldn't network.target mean, "the network is up"? I.e. also the hotplugged devices which are available on boot? > >> For auto interfaces, ifupdown runs the /etc/init.d/networking init > >> script and assumes that at the time the script runs during boot, those > >> interfaces exist. > > Uhm... I though systemd would at a certain point run networking.service > > via LSB compatibility (i.e. /etc/init.d/networking), and that in turn > > runs ifup? > > Sure, that's what I said. What's your point? Guess we've just had a misunderstanding,... you wrote "ifupdown runs the..." so I though you really meant some part of ifupdown and not just what systemd runs from it. > >> My suggestion would be, to make "ifup -a" wait for all auto interfaces > >> to become available with a configurable timeout (60 seconds seems like a > >> good compromise) after which it gives up waiting for the devices, prints > >> a warning and proceeds. > > > > From the systemd side: > > What the long term goals in the sense of: > > If a service needs networking, but networking didn't start, the service > > isn't even tried to be started? > > Or even more detailed: If service postfix, needs eth3, but that didn's > > show up, and wasn't configured,.. postfix won't start either. > > > > Cause if things are ever to be going in such direction, than exiting > > ifup (and ultimately networking) with a timeout, would of course somehow > > need to communicate something like "hey systemd, eth0 and eth3 failed to > > come up, but wlan0 just went up fine". > > Not sure what you're saying. Well right now we have that really strange and troublesome situation that different things bring up different parts of the network (i.e. allow-auto + /etc/init.d/networking vs. allow-hotplug + native system units). And services which need networking also depend on it in a variety of ways: network.target, $network or some do not specify anything at all. But as we all know, network.target/$network are only very loosely defined - people may have multiple network interfaces coming up at different points during boot or even only much later, they may have virtual interfaces like from VPNs, and so on. So what should services (postfix, ssh, etc.) do in the long term to express their network dependency? Depend on network.target (which may or may not include what they actually want - e.g. a VPN interface may only be initialised much later when e.g. openvpn starts), depend on the very network interface which is known to be responsible for their respective address e.g. something like sys-subsystem-net-devices-eth0.device or sys-devices-virtual-net-virbr1.device. Cheers, Chris.
smime.p7s
Description: S/MIME cryptographic signature