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@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 '[email protected]' 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 '[email protected]' 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 '[email protected]' 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
pgpf0LXel9Zo_.pgp
Description: PGP signature
_______________________________________________ Pkg-systemd-maintainers mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
