<html> <head> <base href="https://bugs.freedesktop.org/" /> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW --- - Predictable interface names are inconsistent" href="https://bugs.freedesktop.org/show_bug.cgi?id=59610#c4">Comment # 4</a> on <a class="bz_bug_link bz_status_NEW " title="NEW --- - Predictable interface names are inconsistent" href="https://bugs.freedesktop.org/show_bug.cgi?id=59610">bug 59610</a> from <a class="email" href="mailto:kay@vrfy.org" title="Kay Sievers <kay@vrfy.org>"> Kay Sievers</a> <pre>(In reply to <a href="show_bug.cgi?id=59610#c3">comment #3</a>) > 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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the QA Contact for the bug.</li> <li>You are the assignee for the bug.</li> </ul> </body> </html>