FS#49685 - [dhcpcd] service orders itself too early, delays bootup

Attached to Project: Arch Linux
Opened by Gerry Kessler (renegat) - Sunday, 12 June 2016, 13:27 GMT
Last edited by Toolybird (Toolybird) - Wednesday, 20 September 2023, 03:45 GMT
Task Type Bug Report
Category Packages: Core
Status Closed
Assigned To David Runge (dvzrv)
Giancarlo Razzolini (grazzolini)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 11
Private No

Details

Description:

Description:
With systemd (230-3) there is a significant delay on boot when starting wpa_supplicant (1:2.5-3).
With systemd-boot (no DM used) the cursor starts to flicker weird for ca. 5 seconds than the Message appears:
'A start job is running for dhcpcd on wlp1s0'
wich lasts for ca. 5-10 seconds causing a total delay of ca. 20 seconds (which makes boot last double for me!)

No difference if netctl profile or dhcpcd@.service is used.
Downgraded dhcpcd and wpa_supplicant with no effect.
Issue appears with linux 4.4.13-1-lts and 4.6.2-1

Downgrading systemd and libsystemd to 229-3 solves the issue and arch boots with normal speed again without the 'start job' message.
No entries in logs about it.

Additional info:
package version(s): see above
config and/or log files: not available

Additional info:
package versions: see above
config and/or log files: inexistent


Steps to reproduce: see above
This task depends upon

Closed by  Toolybird (Toolybird)
Wednesday, 20 September 2023, 03:45 GMT
Reason for closing:  Deferred
Additional comments about closing:  Old and stale. No longer seems to be a common issue. The wiki mentions workarounds if you're still affected.
Comment by Dave Reisner (falconindy) - Sunday, 12 June 2016, 14:27 GMT
Unless you can actually pinpoint a bug, I'd suggest you ask for help on the forums. You can start by comparing debug logs between the two versions if you really think this is a systemd problem (I can't see how it is from your description).
Comment by Doug Newgard (Scimmia) - Monday, 13 June 2016, 04:16 GMT
Possibly the same as this? https://bbs.archlinux.org/viewtopic.php?id=213363
Comment by Gerry Kessler (renegat) - Monday, 13 June 2016, 10:00 GMT
Really seems to be the same as https://bbs.archlinux.org/viewtopic.php?id=213363

I thought this issue was related to wireless only as it did not appear with wired network for me.

Comment by Dave Reisner (falconindy) - Monday, 13 June 2016, 11:36 GMT
So the problem isn't really systemd-230, it's that dhcpcd.service has:

Wants=network.target
Before=network.target

This should be changed to network-online.target.
Comment by Ivan Delalande (colona) - Wednesday, 31 August 2016, 08:34 GMT
Patch for the Arch maintainers.

Reference document: https://www.freedesktop.org/wiki/Software/systemd/NetworkTarget/
   dhcpcd-systemd-network-target... (0.7 KiB)
Comment by Laurent Pointecouteau (hellpe) - Sunday, 08 January 2017, 20:29 GMT
Unfortunately, I'm still having this issue with dhcpcd 6.11.5-1. The message "A start job is running for dhcpcd on enp2s0f0" is displayed at bootup, and delays the boot for 1 minute and 30 seconds before resuming.
Comment by Tom Yan (tom.ty89) - Monday, 15 May 2017, 14:00 GMT
The problem is "arg" (@) services shipped by softwares (dhcpcd, wpa_supplicant...) sucks. When they BindsTo= / Requires= + After= a specific device, they should really be WantedBy= the device instead of the multi-user.target. That way it will never block booting because the device does not show up, and the service will be started automatically whenever you plug in the device (and stopped whenever you unplug the device if it is a BindsTo=)

In the dhcpcd case, if you don't want it to stall boot up because of hiccup in getting an IP or so, you could simply override ExecStart= to run it without -w.
Comment by Jarno Malmari (jmalmari) - Saturday, 09 September 2017, 10:49 GMT
The way dhcpcd@.service works, I agree with Dave that network-online.target sounds more like the right one, since the target is waiting for IP address.

But why does dhcpcd.service fork to background immediately, and dhcpcd@.service doesn't?
Comment by rdeckard (rdeckard) - Friday, 16 February 2018, 23:03 GMT
dhcpcd has the following line:

ExecStart=/usr/bin/dhcpcd -q -b

dhcpcd@ has this one:

ExecStart=/usr/bin/dhcpcd -q -w %I

The -w flag is what hangs up the boot. It forces dhcpcd to wait to get an IP address before forking into the background. I think the flag should be removed and these issues would largely be solved.
Comment by Leif Warner (pdxleif) - Thursday, 17 May 2018, 18:48 GMT
You can remove the -w flag - that worked for me. But I went further and changed the service type to "Simple", and removed the pidfile and ExecStop parts from the unit, and changed the flag to -b, to tell it not to fork to the background.
If dhcpcd used some kind of sd_notify thing, you could change the service type to notify if you still wished for systemd to wait for it to acquire an address.
Comment by Vlad-Mihai Sima (vladmihaisima) - Friday, 11 September 2020, 22:21 GMT
  • Field changed: Percent Complete (100% → 0%)
Was this fixed? I still seem to get the issue - hang for long time after reboot. With dhcpcd 9.2.0-1 the file /usr/lib/systemd/system/dhcpcd@.service still has the -w, which might cause the issue.
If this was fixed I can investigate if there is any other problem with the boot, but would like to double check I got the fix...
Comment by Buggy McBugFace (bugbot) - Tuesday, 08 August 2023, 19:11 GMT
This is an automated comment as this bug is open for more then 2 years. Please reply if you still experience this bug otherwise this issue will be closed after 1 month.

Loading...