reassign 766943 to systemd

[Christoph Anton Mitterer]

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 at .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 at .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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5313 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20141122/11524eab/attachment-0002.bin>