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

[Guus Sliepen]

On Tue, Feb 28, 2017 at 04:49:28PM +0100, Maciej Delmanowski wrote:

> > You can still use "ifdown br0" and "ifup br0" if this an auto interface.
> > But I get your point, that then the resulting processes are no longer
> > part of networking.service or a specific cgroup which can be used to
> > reliably kill all process started by ifup.
> 
> Yes, they end up in current user's session CGroup. If 'systemd' is configured
> to kill user processes after logout, this would result in even more broken
> configuration.
> 
> > I think, one solution for this would be, if ifupdown would use
> > ifup at .service for auto interfaces as well, and networking.service would
> > simply become a wrapper/dummy service/target which simply triggers the
> > start of all auto interfaces as instances of ifup at .service.
> 
> That would be fantastic, my wrapper wouldn't be needed in this case.

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.

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.

-- 
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/20170228/345c2677/attachment-0002.sig>