Dhcpcd times out immediately under systemd when there is no carrier

Morn · 2012-09-02 14:53:26

Hi all!

This problem has appeared after moving to a pure systemd installation: dhcpcd no longer gets a lease during boot. I'm using HomePlug AV for my Ethernet connection, so there's initially no carrier on eth0. This causes dhcpcd@eth0.service to quit immediately for some reason:

 # systemctl status dhcpcd@eth0.service 
 dhcpcd@eth0.service - dhcpcd on eth0
          Loaded: loaded (/usr/lib/systemd/system/dhcpcd@.service; enabled)
          Active: failed (Result: exit-code) since Sun, 02 Sep 2012 16:19:34 +0200; 12min ago
         Process: 204 ExecStart=/sbin/dhcpcd -A -q -w %I -t 40 (code=exited, status=1/FAILURE)
          CGroup: name=systemd:/system/dhcpcd@.service/eth0

If I start dhcpcd manually, it also initially complains about the missing carrier but then gets a lease a few seconds later and forks to the background:

# dhcpcd 
dhcpcd[692]: version 5.6.0 starting
dhcpcd[692]: no interfaces have a carrier
dhcpcd[692]: forked to background, child pid 704

Why does dhcpcd@eth0.service quit immediately when there is no carrier? As you can see above, I've tried setting a longer dhcpcd timeout in the .service file (e.g., "-t 40"), but it doesn't seem to get honored by systemd at all.

Everything worked fine with the mixed rc.conf/systemd setup.

Thanks!
Martin

P.S. Here's the log with the systemd and manual invocations of dcpcd:

# journalctl|grep dhc
Sep 02 16:19:34 genesis dhcpcd[204]: version 5.6.0 starting
Sep 02 16:19:34 genesis dhcpcd[204]: eth0: interface not found or invalid
Sep 02 16:19:34 genesis systemd[1]: dhcpcd@eth0.service: control process ex...=1
Sep 02 16:19:34 genesis systemd[1]: Unit dhcpcd@eth0.service entered failed...e.
Sep 02 16:20:13 genesis dhcpcd[692]: version 5.6.0 starting
Sep 02 16:20:14 genesis dhcpcd[692]: no interfaces have a carrier
Sep 02 16:20:14 genesis dhcpcd[704]: eth0: waiting for carrier
Sep 02 16:20:14 genesis dhcpcd[692]: forked to background, child pid 704
Sep 02 16:20:15 genesis dhcpcd[704]: eth0: carrier acquired
Sep 02 16:20:15 genesis dhcpcd[704]: eth0: rebinding lease of 192.168.2.101
Sep 02 16:20:17 genesis dhcpcd[704]: eth0: acknowledged 192.168.2.101 from ....1
Sep 02 16:20:17 genesis dhcpcd[704]: eth0: checking for 192.168.2.101
Sep 02 16:20:22 genesis dhcpcd[704]: eth0: leased 192.168.2.101 for infinity

P.P.S. I've found you can work around this problem by invoking dhcpcd from /usr/lib/systemd/system/dhcpcd@.service without the interface name:

[Service]
Type=forking
PIDFile=/run/dhcpcd.pid
ExecStart=/sbin/dhcpcd

I think systemd should come with a generic dhcpcd service that is not tied to a particular interface like it used to be in rc.conf.

Last edited by Morn (2012-09-02 15:43:21)

aurelieng · 2012-09-03 09:03:45

Same problem here: eth0 is not attributed an IP address, neither after boot, nor after resume. It was working until a few days ago on my pure systemd setup. Any idea ?

Morn · 2012-09-03 09:14:14

I've got this working now as per the PPS, i.e. I just run dhcpcd from systemd without any parameters. I would call it a bug in dhcpcd that the timeout behavior is different between invocations via "dhcpcd" vs e.g. "dhcpcd eth0".

Of course in your case it might be an entirely different issue that's causing this. What does your journalctl output say exactly?

aurelieng · 2012-09-03 09:17:09

Before suspending my laptop, I have:

Sep 03 11:00:37 m6400-arch wicd[443]: dhcpcd[13772]: sending signal 1 to pi...10
Sep 03 11:00:37 m6400-arch dhcpcd[13772]: sending signal 1 to pid 13710
Sep 03 11:00:37 m6400-arch wicd[443]: dhcpcd[13772]: waiting for pid 13710 ...it
Sep 03 11:00:37 m6400-arch dhcpcd[13710]: received SIGHUP, releasing
Sep 03 11:00:37 m6400-arch dhcpcd[13710]: eth0: releasing lease of 130.223.1...7
Sep 03 11:00:37 m6400-arch dhcpcd[13772]: waiting for pid 13710 to exit
Sep 03 11:00:37 m6400-arch dhcpcd[13710]: eth0: removing interface

... going to sleep for a few sec...

Then nothing is logged until I restart the dhcpcd@eth0.service manually:

Sep 03 11:02:25 m6400-arch dhcpcd[13867]: version 5.6.0 starting
Sep 03 11:02:25 m6400-arch dhcpcd[13867]: eth0: sending IPv6 Router Solicitation
Sep 03 11:02:25 m6400-arch dhcpcd[13867]: eth0: broadcasting for a lease
Sep 03 11:02:26 m6400-arch dhcpcd[13867]: eth0: offered 130.223.121.117 from...0
Sep 03 11:02:26 m6400-arch dhcpcd[13867]: eth0: acknowledged 130.223.121.117...0
Sep 03 11:02:26 m6400-arch dhcpcd[13867]: eth0: leased 130.223.121.117 for 1...s
Sep 03 11:02:26 m6400-arch dhcpcd[13867]: forked to background, child pid 13893
Sep 03 11:02:29 m6400-arch dhcpcd[13893]: eth0: sending IPv6 Router Solicitation
Sep 03 11:02:33 m6400-arch dhcpcd[13893]: eth0: sending IPv6 Router Solicitation
Sep 03 11:02:37 m6400-arch dhcpcd[13893]: eth0: sending IPv6 Router Solicitation
Sep 03 11:02:37 m6400-arch dhcpcd[13893]: eth0: no IPv6 Routers available

Last edited by aurelieng (2012-09-03 11:10:53)

falconindy · 2012-09-03 16:01:42

Morn wrote:

I think systemd should come with a generic dhcpcd service that is not tied to a particular interface like it used to be in rc.conf.

Doing this makes it impossible to order things on network.target effectively, as dhcpcd has no way of signaling to systemd that it's bound to an interface and provided an IP.

The generic solution here is to be able to use After=/BindTo= on sys-subsystem-net-device-%i.device, but this is currently broken, and I have no ETA from upstream on a fix.

zacariaz · 2012-09-03 21:32:23

Just wanted to mention that I'm also experiencing this issue.

Also I'm not able to take morns advice and run dhcpcd from systemd without parameters: no such file or directory.

Well, it's annoying nyway, and I'd very much like to see a solution.

Morn · 2012-09-04 09:16:53

Zac, maybe you are on a different interface than eth0? Just edit /usr/lib/systemd/system/dhcpcd@.service directly; the other file is just a symlink to it anyway. Systemd lurves symlinks...

jakobcreutzfeldt · 2012-09-04 10:37:13

I'm not sure if this is related or not but in my case when the computer is suspended and then resumed, the eth0 carrier is lost. I have to manually put down and then bring back up eth0 using ifconfig, and then I have to restart dhcpcd@eth0.service before I can finally connect. Strangely, though, my home laptop has the same setup but I don't have this problem.

zacariaz · 2012-09-04 13:15:48

Morn wrote:

Zac, maybe you are on a different interface than eth0? Just edit /usr/lib/systemd/system/dhcpcd@.service directly; the other file is just a symlink to it anyway. Systemd lurves symlinks...

No that's not it, I simply didn't realize that I needed to include the at sign.

jakobcreutzfeldt wrote:

I'm not sure if this is related or not but in my case when the computer is suspended and then resumed, the eth0 carrier is lost. I have to manually put down and then bring back up eth0 using ifconfig, and then I have to restart dhcpcd@eth0.service before I can finally connect. Strangely, though, my home laptop has the same setup but I don't have this problem.

I don't know about suspended. It seem to make more sense that i fail on that part. In any case, when dhcpcd fail for me, doing a simple systemctl start dhcpcd@eth0.service never fail, well not for me.

Arch Linux

#1 2012-09-02 14:53:26

Dhcpcd times out immediately under systemd when there is no carrier

#2 2012-09-03 09:03:45

Re: Dhcpcd times out immediately under systemd when there is no carrier

#3 2012-09-03 09:14:14

Re: Dhcpcd times out immediately under systemd when there is no carrier

#4 2012-09-03 09:17:09

Re: Dhcpcd times out immediately under systemd when there is no carrier

#5 2012-09-03 16:01:42

Re: Dhcpcd times out immediately under systemd when there is no carrier

#6 2012-09-03 21:32:23

Re: Dhcpcd times out immediately under systemd when there is no carrier

#7 2012-09-04 09:16:53

Re: Dhcpcd times out immediately under systemd when there is no carrier

#8 2012-09-04 10:37:13

Re: Dhcpcd times out immediately under systemd when there is no carrier

#9 2012-09-04 13:15:48

Re: Dhcpcd times out immediately under systemd when there is no carrier

Board footer