Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/index.php/Reporting_Bug_Guidelines

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

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 Anatol Pomozov (anatolik) - Friday, 16 February 2018, 23:08 GMT
Task Type Bug Report
Category Packages: Core
Status Assigned
Assigned To Ronald van Haren (pressh)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 9
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

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 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/
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.

Loading...