Bug#752919: networking scripts runs ifup for hotplugged interfaces, races with net.agent from udev
Andrew Shadura
andrew at shadura.me
Sun Jun 29 00:31:03 BST 2014
Hello,
On Sat, 28 Jun 2014 19:11:46 +0200
Michael Biebl <biebl at debian.org> wrote:
> >> This seems to create a race with the networking SysV init script
> >> which runs also runs ifup for hotplugged interfaces in
> >> ifup_hotplug().
> > Yes, I've noticed that quite a while ago, but haven't found a good
> > way to resolve the issue.
> Can't you just drop if_hotplug() from the networking SysV init script?
> Is there any downside if you do so?
I think a better thing would be to block ifup requests from udev script
until networking initscript has finished, but what you say can be done
as a temporary fix, yes.
> >> Is there a need to ifup allow=hotplug interfaces from within the
> >> networking init script, seeing that net.aget / 80-networking.rules
> >> already cover hotplugged interfaces?
> > Even if I remove that, there's still probability of races, as
> > net.agent blocks on the state of the real interface, while it
> > should wait for ifupdown to do its job first.
> Not quite sure I see the race here, can you elaborate?
When net.agent is called, it checks if lo is up by looking into /sys
directory, and if it's not, it waits. The problem is that the first
thing ifupdown does on boot is configuring lo, so udev script proceeds
immediately causing the race.
> Also given that systemd will be our default init for jessie, we need
> to improve the current systemd integration. E.g. we should ship a
> native .service file for the networking init script handling the
> non-hotplug interfaces. For hotplug interfaces we already have a
> native ifup at .service.
I currently have no idea how those service files are written, but if
you write one, I will add it. Speaking of the integration itself, I
think it'd be good to have a possibility to depend on a specific
interface being up.
> We also need think about how to properly daemons which require
> $network (or network.target in systemd).
> I have a PoC at [1] which provides a ifupdown-wait-online service.
> The implementation is pretty basic, e.g. the criteria for network-up
> is simply that one interface is up (no matter if hotplugged or auto).
> Tollef mentioned, that we should probably refine that, e.g. add
> additional checks for a default gateway or wait for both IPv6 and IPv4
> configuration (given the interface is configured that way).
> As said, it's a prove of concept and would be interested in your
> feedback. Ideally this would go into ifupdown itself.
Sure, that's the proper place for such code. The thing which bothers me
is that ‘being online’ is not a well-defined concept, so we need to
think about it more, I guess.
> I hope you are open to work with us on improving the systemd/ifupdown
> integration.
Well, I don't use systemd myself, but I'm definitely open to work on
this. If I only had more time... I've had many ideas on what could I
change in ifupdown and how, but it's very difficult to allocate
resources for that.
--
Cheers,
Andrew
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20140629/e97e4241/attachment-0002.sig>
More information about the Pkg-systemd-maintainers
mailing list