Bug#818978: New issues with bridges in Debian Jessie/Stretch

[Maciej Delmanowski]

On Feb 28, Guus Sliepen wrote:
> The big issue here is: who is managing the interfaces? Ifupdown or
> systemd? Currently With ifupdown providing 80-ifupdown.rules and
> ifup at service, hotplug interfaces are actually managed by systemd, it
> just is using ifupdown as a low level tool to do the interface
> configuration. Calling ifup/ifdown manually on those interferes with
> systemd. If we also want all auto interfaces to be systemd-managed, then
> there should be a distinction between ifup/ifdown being called from
> systemd and ifup/ifdown being called manually. In the latter case, it
> should then just do "systemd start/stop ifup@$IFACE".
> 
> Maybe it is better to remove the current split between hotplug and other
> interfaces, and have everything managed by ifupdown again. But as you
> say, the issue then is cgroups, so ifupdown then has to learn to start
> its processes in its own dedicated cgroup.

On Feb 28, Michael Biebl wrote:
> Hm, the only clean way I see how this could be done is to turn ifupdown
> into a small daemon which does all the configuration (and lives in it's
> own cgroup). ifup/ifdown would simply send requests to the daemon, but
> not spawn off processes themselves.

Disclaimer: I'm not a Debian Developer, just an user, these are just my
opinions on the matter as an interested third party.

I think that changing the current 'ifupdown' into a daemon is
counter-productive. There's already 'NetworkManager' and
'systemd-networkd' that can be used in similar capacity, although with
a different feature set.

Current scheme for using 'ifupdown' scripts as a low level interface to
network configuration, but calling 'ifup at .service' unit via 'systemd' to place
the processes related to a given network interface in their own CGroup seems
to me as roboust enough. Adding CGroup support to 'ifupdown' directly would
complicate existing code which is not really related to process management
anyway. Let the service manager deal with the processes and focus on the
network configuration itself.

What 'ifupdown' scripts could benefit from, is awerness of the 'systemd' being
the service manager. Detect if the current host is managed by 'systemd', and
if yes, manage the network interfaces via the 'ifup at .service' units instead of
dealing with them directly. This would require separation of 'ifup' and
'ifdown' commands into wrappers which would detect the init system and pass
the command arguments to the appropriate real commands - other init systems
still exist and can be used, so the "old" 'ifupdown' management interface
should still exist. The 'ifup at .service' unit would also use the real commands
in this case, to avoid recursive loops.

On Feb 28, Guus Sliepen wrote:
> I don't like the other option of having all interfaces be systemd
> services. If you want that, I think you're better off converting to
> systemd-networkd.

An important advantage that 'ifupdown' has over
'systemd-networkd' might be support for hook scripts which was rejected for
inclusion in the 'systemd-networkd' in the past:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=798625
This might be useful to some people.

NB, the support for 'ifupdown' configuration in my project is optional, and
I plan to add support for 'systemd-networkd' as an alternative later when time
permits.

Regards,
Maciej
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 585 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20170228/b6a24114/attachment-0002.sig>