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

 * 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' > 

   and reboot. If you catch the bug, please attach "journalctl -b".


Martin Pitt                        | http://www.piware.de
Ubuntu Developer (www.ubuntu.com)  | Debian Developer  (www.debian.org)

Pkg-systemd-maintainers mailing list

Reply via email to