Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 483970 - net-misc/dhcpcd-5.6.4 with sys-apps/systemd-204 - netinterfaces naming : device or ressource busy
Summary: net-misc/dhcpcd-5.6.4 with sys-apps/systemd-204 - netinterfaces naming : devi...
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: [OLD] Core system (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: William Hubbs
URL:
Whiteboard:
Keywords: PATCH
Depends on:
Blocks:
 
Reported: 2013-09-06 11:07 UTC by nico
Modified: 2013-09-20 17:00 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
dhcpcd@.service (dhcpcd@.service,334 bytes, text/plain)
2013-09-06 11:11 UTC, nico
Details

Note You need to log in before you can comment on or make changes to this bug.
Description nico 2013-09-06 11:07:42 UTC
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
Comment 1 nico 2013-09-06 11:11:37 UTC
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
Comment 2 Pacho Ramos gentoo-dev 2013-09-06 18:31:32 UTC
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
Comment 3 Mike Gilbert gentoo-dev 2013-09-06 20:04:54 UTC
(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.
Comment 4 Pacho Ramos gentoo-dev 2013-09-06 20:31:55 UTC
Yeah, I saw it after adding the comment and, then, I added the other bug to the "See also" field ;)
Comment 5 William Hubbs gentoo-dev 2013-09-08 18:35:56 UTC
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
Comment 6 Mike Gilbert gentoo-dev 2013-09-08 19:21:55 UTC
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.
Comment 7 William Hubbs gentoo-dev 2013-09-09 00:57:38 UTC
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
Comment 8 Roy Marples 2013-09-09 16:32:42 UTC
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.
Comment 9 Roy Marples 2013-09-09 20:51:00 UTC
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.
Comment 10 William Hubbs gentoo-dev 2013-09-09 22:32:16 UTC
@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
Comment 11 Mike Gilbert gentoo-dev 2013-09-10 00:18:49 UTC
(In reply to William Hubbs from comment #10)

I just tried this in a virtual machine, and the problem still occurs.
Comment 12 Mike Gilbert gentoo-dev 2013-09-10 00:42:06 UTC
Also of note: If I add "denyinterfaces eth*" to dhcpcd.conf, udev is able to rename the interface, but dhcpcd continues to ignore it.
Comment 13 Mike Gilbert gentoo-dev 2013-09-10 02:21:42 UTC
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
Comment 14 nico 2013-09-10 07:04:44 UTC
(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
Comment 15 Roy Marples 2013-09-10 08:55:57 UTC
(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
Comment 16 Roy Marples 2013-09-10 09:58:09 UTC
(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.
Comment 17 Mike Gilbert gentoo-dev 2013-09-10 14:53:06 UTC
It seems to be working consistently here.
Comment 18 William Hubbs gentoo-dev 2013-09-10 21:20:01 UTC
It still looks good here (udev, but not with systemd).

Roy,

what are your plans for spinning a new release?

Thanks,

William
Comment 19 Roy Marples 2013-09-11 12:31:26 UTC
(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.
Comment 20 Roy Marples 2013-09-12 22:59:17 UTC
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.
Comment 21 Roy Marples 2013-09-18 07:52:08 UTC
Nothing to report or no testing done?
Lets see if I can push a new build out this weekend instead.
Comment 22 William Hubbs gentoo-dev 2013-09-20 17:00:07 UTC
Please re-open this bug if the issue re-occurs with >= dhcpcd-6.1.0.

Thanks much,

William