After booting, the net interface name cannot be rename by systemd-udevd Reproducible: Always Steps to Reproduce: 1. emerge -q =net-misc/dhcpc-5.6.4 =sys-apps/systemd-204 2. systemctl enable dhcpcd 3. reboot Actual Results: systemd-udevd[3253]: error changing net interface name eth0 to enp11s0: Device or resource busy Expected Results: systemd-udevd[3311]: renamed network interface eth0 to enp11s0
Created attachment 358032 [details] dhcpcd@.service I avoided the problem by using another unit file : - creating /etc/systemd/system/dhcpcd\@.service - systemctl disable dhcpcd - systemctl enable dhcpcd\@enp11s0
This is similar to: https://projects.archlinux.org/svntogit/packages.git/tree/trunk/dhcpcd_.service?h=packages/dhcpcd But try to avoid "Type=forking", try this: [Unit] Description=Lightweight DHCP client daemon on %I Wants=network.target Before=network.target BindsTo=sys-subsystem-net-devices-%i.device After=sys-subsystem-net-devices-%i.device [Service] ExecStart=/sbin/dhcpcd --nobackground -q -w %I ExecStop=/sbin/dhcpcd --nobackground -x %I [Install] WantedBy=multi-user.target
(In reply to Pacho Ramos from comment #2) > This is similar to: > https://projects.archlinux.org/svntogit/packages.git/tree/trunk/dhcpcd_. > service?h=packages/dhcpcd > > But try to avoid "Type=forking", try this: I am reasonably certain that the -w/--waitip option will not have any useful effect unless you use forking mode.
Yeah, I saw it after adding the comment and, then, I added the other bug to the "See also" field ;)
This bug indicates a couple of things. First there should be a service like the one mentioned that can be used to start dhcpcd on individual interfaces, but dhcpcd.service also seems to be starting the standalone version before udev can rename the interfaces
The error reported by the original reporter is pretty harmless, and it really only matters if the user has some custom per-interface configuration or needs the interface to have a specific name. In that case I would recommend adding a line like the following to dhcpcd.conf: denyinterfaces eth* This should cause dhcpcd to ignore the interface until it has been renamed by udev.
I spoke with Kay, the udev author, and was told that this is caused by a race condition between dhcpcd and udev. Since dhcpcd is listening to the netlink socket directly, it is possible for dhcpcd to grab the interface and configure it before udev can rename it. His recommendation is that dhcpcd should handle devices by using libudev on Linux instead of using the netlink socket directly; he pointed to this example [1]. This is not an example for network devices, but handling network devices would probably be similar. Roy, What do you think about using libudev to handle devices on Linux systems? [1] http://article.gmane.org/gmane.linux.hotplug.devel/13925
Well, as libudev seems to be installed to /lib dhcpcd can use it. I've added an initial patch for it here: http://roy.marples.name/projects/dhcpcd/changeset/ba375fbeda336b6b41a2eb076df476689599d5b0 With a final fix to detect udev subsystem filtering here: http://roy.marples.name/projects/dhcpcd/changeset/01849df3217e204ee9d9d43f13e45acd2822d8f8 If the udev USE flag is still around the checking for it can be disabled with --without-udev libudev is ONLY used for interface arrival/departure. dhcpcd will still use netlink for everything else. Testing on this welcome.
I've working on it some more and it all seems to work fine, even handles live interface renaming now. Appreciate some testing to see if it resolved the OP as I don't have or use systemd.
@mico: Please do the following: 1) upgrade to dhcpcd-9999. 2)switch back to the provided service file. 3) reboot and let us know if that fixes the issue. Thanks, William
(In reply to William Hubbs from comment #10) I just tried this in a virtual machine, and the problem still occurs.
Also of note: If I add "denyinterfaces eth*" to dhcpcd.conf, udev is able to rename the interface, but dhcpcd continues to ignore it.
Roy: I think you are missing a call to udev_device_get_is_initialized(). http://www.freedesktop.org/software/systemd/libudev/libudev-udev-device.html#udev-device-get-is-initialized
(In reply to William Hubbs from comment #10) > @mico: > Please do the following: > 1) upgrade to dhcpcd-9999. > 2)switch back to the provided service file. > 3) reboot and let us know if that fixes the issue. > > Thanks, > > William I tried with dhcpcd-9999 (aka 6.0.5), the interface is renamed right after a reboot, but I encounter another problem: dhcpcd[3292]: no interfaces have a carrier. I needed to restart by hand dhcpcd service to make the interface up: - systemctl restart dhcpcd
(In reply to Mike Gilbert from comment #13) > Roy: I think you are missing a call to udev_device_get_is_initialized(). > > http://www.freedesktop.org/software/systemd/libudev/libudev-udev-device. > html#udev-device-get-is-initialized Added here: http://roy.marples.name/projects/dhcpcd/changeset/b3c17b13eb7faf56c68d15f48f0ea105bda1a323 Thanks Mike
(In reply to nico from comment #14) > I tried with dhcpcd-9999 (aka 6.0.5), the interface is renamed right after a > reboot, but I encounter another problem: > > dhcpcd[3292]: no interfaces have a carrier. > > I needed to restart by hand dhcpcd service to make the interface up: > - systemctl restart dhcpcd I think I have this fixed now. Please all test and report again.
It seems to be working consistently here.
It still looks good here (udev, but not with systemd). Roy, what are your plans for spinning a new release? Thanks, William
(In reply to William Hubbs from comment #18) > Roy, > > what are your plans for spinning a new release? New release soon as all known issues are resolved. Over the weekend at the latest I think.
I just pushed a large architectural change to dhcpcd which moves the udev code into a dev plugin. I basic idea is that the plugin is linked to libudev and not dhcpcd, so in the event of udev missing or not working, dhcpcd can still function. I'm happy with this and have regression tested on all my OS, but still request more testing again. Ideally from the OP.
Nothing to report or no testing done? Lets see if I can push a new build out this weekend instead.
Please re-open this bug if the issue re-occurs with >= dhcpcd-6.1.0. Thanks much, William