Hello Wolfgang, Wolfgang Walter [2016-09-14 23:34 +0200]: > > > I tested this with a script:
FTR, I tried this as welll, and I cannot reproduce the bug either. Wolfgang Walter [2016-09-14 17:56 +0200]: > Yes, systemd-networkd ist active. But on most machines I only have *.link > entries, usually one to name the device: *.link entries are handled by udev, not networkd. So if you can reproduce this on a machine with only has files like > ====================== > [Match] > MACAddress=11:22:33:44:55:66 > > [Link] > Name=net > WakeOnLan=off > ====================== then can you please "systemctl disable --now systemd-networkd" and check if the problem still happens? I suppose not, but if so, this tells us that this is being done through udev. If networkd itself is really the culprit, can you please try the following: * Keep it disabled, run your test.sh to set up the dummy interface, and run SYSTEMD_LOG_LEVEL=debug /lib/systemd/systemd-networkd (as root). Does this now cause the addresses to be removed? This will run much later than test.sh, so this will tell us if this is a principal logic error or a race condition, i. e. only happens if networkd starts at the right time after test.sh. * Enable networkd again, and boot with "debug" in the kernel command line. Does this still reproduce the bug? If so, please attach the output of "journalctl -b". If not, just enable debugging for networkd with mkdir -p /etc/systemd/system/systemd-networkd.service.d/ printf '[Service]\nEnvironment=SYSTEMD_LOG_LEVEL=debug' > /etc/systemd/system/systemd-networkd.service.d/debug.conf and reboot. If you catch the bug, please attach "journalctl -b". Thanks, Martin -- Martin Pitt | http://www.piware.de Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)