Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
FS#39527 - [dhcpcd] systemd unit file: disable wpa_supplicant hook
Attached to Project:
Arch Linux
Opened by Michael B. (mgb) - Tuesday, 18 March 2014, 14:25 GMT
Last edited by Doug Newgard (Scimmia) - Thursday, 14 April 2016, 13:55 GMT
Opened by Michael B. (mgb) - Tuesday, 18 March 2014, 14:25 GMT
Last edited by Doug Newgard (Scimmia) - Thursday, 14 April 2016, 13:55 GMT
|
DetailsDescription:
dhcpcd has a client hook to start wpa_supplicant This dhcpcd function should be disabled in dhcpcd unit file: when systemd is installed, wpa_supplicant is managed/controlled by systemd To start dhcpcd without wpa_supplicant the option "-C wpa_supplicant" is needed: diff /etc/systemd/system/dhcpcd.service /lib/systemd/system/dhcpcd.service 9c9 < ExecStart=/usr/bin/dhcpcd -q -b -C wpa_supplicant --- > ExecStart=/usr/bin/dhcpcd -q -b Additional info: * package version(s) uname -r ; systemctl --version; dhcpcd --version 3.13.6-1-ARCH systemd 211 +PAM -LIBWRAP -AUDIT -SELINUX -IMA -SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ +SECCOMP -APPARMOR dhcpcd 6.3.1 Copyright (c) 2006-2014 Roy Marples * config and/or log files etc. Under "normal" conditions this issue "should" never happen. But the better / more stable setup is to prevent wpa_supplicant from beeing started by dhcpcd. |
This task depends upon
Closed by Doug Newgard (Scimmia)
Thursday, 14 April 2016, 13:55 GMT
Reason for closing: Fixed
Additional comments about closing: Upstream
Thursday, 14 April 2016, 13:55 GMT
Reason for closing: Fixed
Additional comments about closing: Upstream
I would like to know what is true about this wiki edit [1] (made by the submitter of this bug), especially the second point:
* dhcpcd starts wpa_supplicant daemon during boot (this can result in systemd-udevd error: "error changing net interface name wlan0 to wlp4s0: Device or resource busy" and can prevent "Predictable Network Interface Names" )
Also note that core/wpa_supplicant installs the sample config file at /etc/wpa_supplicant/wpa_supplicant.conf (read by dhcpcd's wpa_supplicant hook) and it has uncommented several options and all network blocks. As a result, after installing dhcpcd + wpa_supplicant and running dhcpcd on wireless interface, the wpa_supplicant daemon is indeed started and does not produce any obvious error, all without any user intervention. IMO it would be better to install the sample wpa_supplicant config at /usr/share/doc/wpa_supplicant/wpa_supplicant.conf, which is even suggested in the man page.
[1]: https://wiki.archlinux.org/index.php?title=Dhcpcd&diff=305559&oldid=304450
- the unit file is shipped with arch linux and is about using dhcpcd with systemd
- when systemd + dhcpcd is used: wpa_supplicant should be started from systemd
- dhcpcd is started from systemd with the proposed change in unit file and does no longer start wpa_supplicant
This is smarter than changing dhcpcd.conf. Even better is to post unit files upstream & avoid this patches in archlinux ...
The limitation of this proposal: it does not work when someone tries to control wpa_supplicant from dhcpcd and not from systemd.
The rest of your comment is off topic, from my point of view: This is about how to avoid issues with wpa_supplicant started twice. This will never happen under "normal" conditions, but can happen from time to time (check e.g. bug reports for dhcpcd and internet). It is a precautionary solution to make things more stable.
It makes no sense to post (or discuss) elementary suggestions at very beginner level here.
1) is the interface wireless
2) dhcpcd needs to be able to find wpa_supplicant.conf
3) ctrl_interface needs to be enabled in wpa_supplicant.conf
4) wpa_cli needs to be able to detect that wpa_supplicant is not running for the interface in question
Once all 4 points are satisfied, dhcpcd will start wpa_supplicant for the interface.
Of course the correct fix is to add code to stop wpa_supplicant from allowing itself to spawn another time for the interface.
EDIT:
wpa_supplicant can now monitor hotplugged interfaces:
http://w1.fi/cgit/hostap/commit/?id=2e997eece5776eca0a99d53893e343539f9f8eb2