Bug 59610

(In reply to comment #0)
> * Fresh Arch Linux installation using 2012-12 media
> * systemd 194-4

194? It should not have that facility, it was added with 197.

> Steps causing discovery (internal WLAN):
> 
> 1) Observe predictable name (wlp6s2)
> 2) rmmod/modprobe module for interface (e.g. ipw2200)
> 3) Observe non-predictable name (eth0)

That works all fine here, it's probably some weird issue on your system.

# udevadm monitor -k &
[1] 993

[root@lon linux]# rmmod iwldvm
KERNEL[1259.571489] remove   /devices/pci0000:00/0000:00:1c.1/0000:03:00.0/net/wlp3s0 (net)
KERNEL[1259.595598] remove   /module/iwldvm (module)

[root@lon linux]# modprobe iwldvm
KERNEL[1271.599902] add      /module/iwldvm (module)
KERNEL[1271.611701] add      /devices/pci0000:00/0000:00:1c.1/0000:03:00.0/net/wlan0 (net)
[root@lon linux]# KERNEL[1271.619997] move     /devices/pci0000:00/0000:00:1c.1/0000:03:00.0/net/wlp3s0 (net)

Okay, very embarrased because it is supposed to say "systemd 197-4". I should really have copy/pasted it rather than typing it out. My apologies!

I just tried both sets of steps again.. and it works as expected now. The only thing I have done since coming across this bug is change from the dhcpcd service to a bonding configuration controlled by netcfg.

Reverting this change, reinstates the behaviour I report. When using 'dhcpcd.service', interfaces are not given persistent names, but are when using alternatives (netcfg in my case). Are you using dhcpcd.service and if not, is it something you could easily test?

Also, is it possible there may be a race condition between the dhcpcd service and the udev renaming which prevents the rename because dhcpcd has already took control of the interface? I'm not familiar with the interaction between the two so it is just a guess..

Thank you very much for testing it on your machine, that has definitely managed to narrow down the problem!

I have included the output of 'udevadm monitor' that I get while the problem is present:

$ udevadm monitor -k &
[1] 320

$ sudo rmmod ipw2200
KERNEL[63.438292] remove   /devices/pci0000:00/0000:00:1e.0/0000:06:02.0/net/wlp6s2/queues/rx-0 (queues)
KERNEL[63.439512] remove   /devices/pci0000:00/0000:00:1e.0/0000:06:02.0/net/wlp6s2/queues/tx-0 (queues)
KERNEL[63.440170] remove   /devices/pci0000:00/0000:00:1e.0/0000:06:02.0/net/wlp6s2 (net)
KERNEL[63.446875] remove   /devices/pci0000:00/0000:00:1e.0/0000:06:02.0/ieee80211/phy0/rfkill0 (rfkill)
KERNEL[63.453444] remove   /devices/pci0000:00/0000:00:1e.0/0000:06:02.0/ieee80211/phy0 (ieee80211)
KERNEL[63.453583] remove   /bus/pci/drivers/ipw2200 (drivers)
KERNEL[63.453928] remove   /module/ipw2200 (module)
$ sudo modprobe ipw2200
KERNEL[68.076723] add      /module/ipw2200 (module)
KERNEL[68.079463] add      /devices/pci0000:00/0000:00:1e.0/0000:06:02.0/firmware/0000:06:02.0 (firmware)
KERNEL[68.083738] remove   /devices/pci0000:00/0000:00:1e.0/0000:06:02.0/firmware/0000:06:02.0 (firmware)
KERNEL[68.208959] add      /devices/pci0000:00/0000:00:1e.0/0000:06:02.0/ieee80211/phy1 (ieee80211)
KERNEL[68.209723] add      /devices/pci0000:00/0000:00:1e.0/0000:06:02.0/ieee80211/phy1/rfkill1 (rfkill)
KERNEL[68.210868] change   /devices/pci0000:00/0000:00:1e.0/0000:06:02.0/ieee80211/phy1/rfkill1 (rfkill)
KERNEL[68.211121] add      /devices/pci0000:00/0000:00:1e.0/0000:06:02.0/net/eth0 (net)
KERNEL[68.212443] add      /devices/pci0000:00/0000:00:1e.0/0000:06:02.0/net/eth0/queues/rx-0 (queues)
KERNEL[68.212602] add      /devices/pci0000:00/0000:00:1e.0/0000:06:02.0/net/eth0/queues/tx-0 (queues)
KERNEL[68.216810] add      /bus/pci/drivers/ipw2200 (drivers)

(In reply to comment #1)

Continuing from my above comment (which should have been a reply, I've not done well getting things right these early hours), I have done some further testing at the suggestion of someone in #archlinux.

Stopping dhcpcd.service and starting dhcpcd@wlp6s2 also fixes this behaviour (the device gets wlp6s2 back when rmmod/modprobed). So the issue is specifically with the dhcpcd.service interfering with the device renaming.

I just ran 'udevadm monitor -k & ' while reloading the module with dhcpcd.service stopped and I can now also see the 'move' to the new name. dhcpcd.service seems to be grabbing the interface as soon as it is added, preventing udev from renaming it.

(In reply to comment #3)

> Stopping dhcpcd.service and starting dhcpcd@wlp6s2 also fixes this behaviour
> (the device gets wlp6s2 back when rmmod/modprobed). So the issue is
> specifically with the dhcpcd.service interfering with the device renaming.
> 
> I just ran 'udevadm monitor -k & ' while reloading the module with
> dhcpcd.service stopped and I can now also see the 'move' to the new name.
> dhcpcd.service seems to be grabbing the interface as soon as it is added,
> preventing udev from renaming it.

Yeah, interfaces which are brought up cannot be renamed.

Udev does not send out any events before it has finished renaming the
interface, so there is usually something in udev rules, or the running
service listens to rtnetlink and watches devices on its own and is bringing
them up.

It should probably only be systemd which starts dhcpcd when a device appears,
and the service should not listen to device creation itself.

This looks like the same issue?

https://bugs.freedesktop.org/show_bug.cgi?id=59964

(In reply to comment #5)
> This looks like the same issue?
> 
> https://bugs.freedesktop.org/show_bug.cgi?id=59964

No, not really. #59964 is about expecting to have devices present when network.target is reached. Marking it as a duplicate would muddy things.

This one looks like a bug (incompatibility with udev's renaming) in dhcpd. Kernel's protocol for device renaming allows other services to "interfere", and like Kay said, dhcpd should back off the device until udev has done its job.

Not our bug, IMHO.

Is there a reason why udev cannot down the interface when it wants to rename?

Once renamed, the kernel should announce the departure of the old name and the arrival of the new name via netlink which dhcpcd will spot and then configure happily on the new name.

(In reply to comment #7)
> Is there a reason why udev cannot down the interface when it wants to rename?
> 
> Once renamed, the kernel should announce the departure of the old name and
> the arrival of the new name via netlink which dhcpcd will spot and then
> configure happily on the new name.

Nope, we should not interfere with dhcpd's operation the same way as dhcpc shouldn't interfere with udev's. It's pretty simple: as long as the device hasn't been announced by udev dhcpcd shouldn't take possession of it. And as long soon as udev announced the device it shouldn't touch it anymore.