FS#49913 - [wpa_supplicant] system hangs on boot when no access point is available
Attached to Project:
Arch Linux
Opened by Nico Schottelius (telmich) - Saturday, 02 July 2016, 07:49 GMT
Last edited by Gerardo Exequiel Pozzi (djgera) - Saturday, 02 July 2016, 16:20 GMT
Opened by Nico Schottelius (telmich) - Saturday, 02 July 2016, 07:49 GMT
Last edited by Gerardo Exequiel Pozzi (djgera) - Saturday, 02 July 2016, 16:20 GMT
|
Details
Description:
When having wpa_supplicant@wlp4s0.service enabled and there is no access point available, I have to wait 1.5 minutes to be able to login. This seems like a very bad dependency configuration. Additional info: * package version(s) * config and/or log files etc. [16:45] wurzel:~% pacman -Q | grep -e systemd -e wpa_supp lib32-systemd 230-1 libsystemd 230-5 systemd 230-5 systemd-sysvcompat 230-5 wpa_supplicant 1:2.5-3 wpa_supplicant_gui 2.5-3 [16:45] wurzel:~% Steps to reproduce: - create /etc/wpa_supplicant/wpa_supplicant-wlp4s0.conf with some essids - enable wpa_supplicant@wlp4s0.service (or whatever your wifi device is) - reboot without any accessible access point - wait for 1.5 minutes |
This task depends upon
Closed by Gerardo Exequiel Pozzi (djgera)
Saturday, 02 July 2016, 16:20 GMT
Reason for closing: Not a bug
Saturday, 02 July 2016, 16:20 GMT
Reason for closing: Not a bug
Nothing in wpa_supplicant@.service will produce the timeout that you describe, blocking bootup.
it doesn't seem to be the case:
[00:13:10] wurzel:~# systemctl --reverse list-dependencies network-wait-online.service
network-wait-online.service
[00:13:19] wurzel:~# systemctl --reverse list-dependencies network-online.target
network-online.target
[00:13:32] wurzel:~#
However, there are units depending on wpa_supplicant:
[00:14:51] wurzel:~# systemctl --reverse list-dependencies wpa_supplicant@wlp4s0.service
wpa_supplicant@wlp4s0.service
● └─multi-user.target
● └─graphical.target
[00:14:57] wurzel:~#
And this seems to confirm the behaviour that I see.
I've removed the links from /etc/systemd/system/multi-user.target.wants/ and rerun systemctl enable and now it works correctly.
Sorry for the noise, please close the task.