On Feb 28, Michael Biebl wrote: >>> allow-hotplug br0 >> >> Using allow-hotplug for bridge interfaces is not a good idea. You really >> should use that for physical hardware only, which actually is "plugged in". >> >> If you want to treat it like hotplugged hardware, you have to create the >> interfaces yourself (using brctl), as you already noted. >> >> So, this is really a misconfiguration imho. >> >> Use "auto br0" and you should be fine.
Unfortunately, using ifupdown auto/hotplug configuration complicates things when 'systemd' is introduced. To summarize explanation found in https://lists.debian.org/debian-user/2015/04/msg01208.html: The 'auto <interface>' stanza is used by the 'networking.service' which starts network interfaces on boot. All of the network interface processes, like 'dhclient', started this way end up in one 'networking.service' CGroup. The downside of this is that modifications to interface layout need to stop and start all of the network interfaces at once, using 'networking.service'. This might not apply anymore on Debian Stretch, but it still applies in Debian Jessie. The 'hotplug <interface>' stanza is used by the '[email protected]' which starts each network interface processes, like 'dhclient', in its own separate CGroup. This allows modification of each network interface separately and doesn't result in disruption in connectivity when non-default network interfaces are modified. One problem with this is that the '[email protected]' interfaces are not brought up automatically at boot. For this, I created a separate 'systemd' service https://github.com/debops/ansible-ifupdown/blob/master/templates/etc/systemd/system/ifup-allow-boot.service.j2 This service is executed just after `networking.service` and brings up all network interfaces marked as 'allow-boot' using calls to `[email protected]` units. The current mechanism is probably horrible, shelling out to start another service unit doesn't seem like an efficient idea, is there a better interface for this? Anyhow, this mechanism works as long as the interfaces are marked as 'allow-hotplug', otherwise '[email protected]' doesn't even touch a given interface due to the use of '--allow=hotplug' in the unit arguments. The above changes are very important to me because I'm using Ansible to modify network interface configuration remotely. Without these changes remote network configuration becomes unreliable, there's no way to be sure if there's no rough 'dhclient' process for a given network interface that might mess up networking. Using separate CGroups for each network interface makes network configuration reliable. I've checked your suggestion with dropping the 'hotplug br0' and adding the 'auto br0' stanza for the bridge, and this solution works, but the result is that the 'dhclient' process ends up in the 'networking.service' CGroup. I suppose that a solution for this would be for my custom service to create the bridge interface manually before calling '[email protected]', but that doesn't fix the usage later when the service can be stopped and started separately. Directly creating the symlinks for each network interface in '/etc/systemd/system/' won't work either because the '[email protected]' only runs for network interfaces marked with 'allow-hotplug'. Guus Sliepen <[email protected]> wrote: > > > It seems that the latest changes in the 'systemd' package result in issues > > > with configuration of network bridges. I can reproduce this issue > > > reliably on > > > Debian Jessie KVM guest, and most likely on Debian Stretch KVM guest > > > (haven't > > > tried repeatedly yet). > Hm, what does this have to do with bug 818978, which is about systemd > crashing in LXC containers? I'm not sure if it's directly related to this bug. Perhaps its due to other changes introduced in the 215-17+deb8u6 version of the 'systemd' package. After checking the changelog for the Debian Jessie package http://metadata.ftp-master.debian.org/changelogs/main/s/systemd/systemd_215-17+deb8u6_changelog it seemed to be the only related change. I wasn't able to get the 215-17+deb8u5 version from snapshot.debian.org for some reason, but 215-17+deb8u4 version worked without the issue. Any suggestions on how to proceed would be appreciated. Thanks for your work and best regards, Maciej
pgpoMwANghbxT.pgp
Description: PGP signature
_______________________________________________ Pkg-systemd-maintainers mailing list [email protected] http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
