wpa_supplicant@wifi stalling boot if adaptor not plugged in

ioquatix · 2017-05-14 05:35:50

I'm using systems-networkd with wpa_supplicant, and it works fine.

I've actually got two different wifi adapters - but I don't always have both plugged in (one is AC and one is N). The reason for this is the AC one sometimes fails to work when the kernel is updated and so I use the generic N wifi to fix things

I've got wpa_supplicant enabled like so:

# ls -lah /etc/systemd/system/multi-user.target.wants 
total 8.0K
drwxr-xr-x 2 root root 4.0K Nov  5  2016 .
drwxr-xr-x 6 root root 4.0K May  9  2016 ..
lrwxrwxrwx 1 root root   44 May  9  2016 avahi-daemon.service -> /usr/lib/systemd/system/avahi-daemon.service
lrwxrwxrwx 1 root root   40 May  6  2016 remote-fs.target -> /usr/lib/systemd/system/remote-fs.target
lrwxrwxrwx 1 root root   36 May 11  2016 sshd.service -> /usr/lib/systemd/system/sshd.service
lrwxrwxrwx 1 root root   48 May 12  2016 systemd-networkd.service -> /usr/lib/systemd/system/systemd-networkd.service
lrwxrwxrwx 1 root root   48 May 12  2016 systemd-resolved.service -> /usr/lib/systemd/system/systemd-resolved.service
lrwxrwxrwx 1 root root   47 Sep 17  2016 wpa_supplicant@wifi1.service -> /usr/lib/systemd/system/wpa_supplicant@.service
lrwxrwxrwx 1 root root   47 Nov  5  2016 wpa_supplicant@wifi2.service -> /usr/lib/systemd/system/wpa_supplicant@.service

I only ever have one network adaptor plugged in, so at boot, it waits for 1min 30s:

A start job is running for sys-subsystem-net-devices-wifi2.device (xxs / 1min 30s)

Is there any way I can avoid this?

Last edited by ioquatix (2017-05-14 05:36:33)

Trilby · 2017-05-14 12:01:08

Disable the one you don't normally use.

If the kernel is updated and the AC doesn't work, then start wpa_supplicant on the N as needed - not on every boot.

ioquatix · 2017-05-14 12:02:31

Thanks. Yes, that's an option. But surely it's possible to say "This thing is not essential please do it in the background"?

Trilby · 2017-05-14 12:05:56

surely, it is.

tom.ty89 · 2017-05-15 07:01:09

The wpa_supplicant@ service sucks. Same case goes to the dhcpcd@ service. Having the multi-user target pulls them while they require their devices means the having the multi-user target indirectly requires the devices.

You can have something like this in /etc/systemd/system/ instead:

[Unit]
Description=WPA supplicant daemon (interface-specific version)
BindsTo=sys-subsystem-net-devices-%i.device
After=sys-subsystem-net-devices-%i.device
Before=network.target
Wants=network.target

# NetworkManager users will probably want the dbus version instead.

[Service]
Type=simple
ExecStart=/usr/bin/wpa_supplicant -c/etc/wpa_supplicant/wpa_supplicant-%I.conf -i%I

[Install]
WantedBy=sys-subsystem-net-devices-%i.device

1. Make the service being wanted by the device instead of the multi-user target, so it will be started only when the device shows up.
2. Change Requires= to BindsTo=. Start job for the device doesn't really make a point, but BindsTo= implies Requires= anyway (which sucks as well). The change to BindsTo= guarantees the service to be stopped when the device disappear (unplugged).

Last edited by tom.ty89 (2017-05-15 07:25:45)

Trilby · 2017-05-15 10:53:30

Or just remove network.target from the "After=" line of whatever service is actually causing the problem.

rsmarples · 2017-05-15 12:23:35

Or, if the wpa_supplicant is new enough, stop starting it for a specific interface and let wpa_supplicant work it out.
For example, to start wpa_supplicant on all applicable interfaces using /etc/wpa_supplicant.conf

wpa_supplicant -M /etc/wpa_supplicant.conf

Limit it to specific interfaces using fnmatch(3)

wpa_supplicant -M -c /etc/wpa_supplicant.conf -i "wlan*"

ioquatix · 2017-05-15 12:25:21

rsmarples wrote:

Or, if the wpa_supplicant is new enough, stop starting it for a specific interface and let wpa_supplicant work it out.
For example, to start wpa_supplicant on all applicable interfaces using /etc/wpa_supplicant.conf
wpa_supplicant -M /etc/wpa_supplicant.conf
Limit it to specific interfaces using fnmatch(3)
wpa_supplicant -M -c /etc/wpa_supplicant.conf -i "wlan*"

That's a really interesting approach, and that was my intuitive first guess - why can't spa_supplicant figure it out.

tom.ty89 · 2017-05-15 12:50:33

Trilby wrote:

Or just remove network.target from the "After=" line of whatever service is actually causing the problem.

You mean After=sys-subsystem-net-devices-%i.device right? With that approach the service probably fails quickly so it won't block the boot, but pointless start job will still be spawned for the device in "background" and time out after 1m30s. Maybe it's a bug, and maybe it's harmless, it's silly anyway.

Also you will need to manually start the service with systemctl when you insert the device later that way.

Btw, the wpa_supplicant service probably should not even have these lines:

Before=network.target
Wants=network.target

I think they only belong to whatever configure IP/route for the device (e.g. dhcpcd). So instead you can have:

Wants=dhcpcd@%i.service
Before=dhcpcd@%i.service

IF you want dhcpcd to configure it.

Last edited by tom.ty89 (2017-05-15 12:55:07)

Trilby · 2017-05-15 13:09:11

tom.ty89 wrote:

You mean After=sys-subsystem-net-devices-%i.device right?

No. I mean precisely what I said and what I linked to in my first response here.

The problem is not in the networking services, it's that systemd-user services now have a hard dependency on network.target - that is what should be changed. Don't try to lie about the network being up - just change whether or not your user session should really require a network connection before it starts if that's what you want to change.

tom.ty89 · 2017-05-15 13:42:47

Oh I didn't really read what you linked carefully.

But I beg to differ. systemd-user-sessions.service does not have "hard dependency" on network.target, it is only ordered after it. It seem to make sense because if there's a chance systemd-user-sessions needs network, surely it should be ordered after network target.

Instead of a dependency issue, it's more of a ordering cycle issue. Again, having the device start the the @ service(s) is the solution, that way network.target won't even be brought to the boot order chain if the device does not show up.

Certainly, dhcpcd can be stalled even when the device shows up on boot, in that case if you don't need the network access to be waited, you should probably change the way it runs dhcpcd (without -w). For wpa_supplicant there wouldn't be such an issue because it's a Type=simple.

Last edited by tom.ty89 (2017-05-15 13:47:46)

rsmarples · 2017-05-15 14:20:47

tom.ty89 wrote:

Certainly, dhcpcd can be stalled even when the device shows up on boot

For wireless (at boot), dhcpcd generally starts before association sees there's no carrier and forks to the background.
dhcpcd only "stalls" when it's negotiating an address on an interface with carrier up and it's not getting a reply.
If you don't like this, you can easily add the -b flag to dhcpcd to say "just fork into the background".

Arch Linux

#1 2017-05-14 05:35:50

wpa_supplicant@wifi stalling boot if adaptor not plugged in

#2 2017-05-14 12:01:08

Re: wpa_supplicant@wifi stalling boot if adaptor not plugged in

#3 2017-05-14 12:02:31

Re: wpa_supplicant@wifi stalling boot if adaptor not plugged in

#4 2017-05-14 12:05:56

Re: wpa_supplicant@wifi stalling boot if adaptor not plugged in

#5 2017-05-15 07:01:09

Re: wpa_supplicant@wifi stalling boot if adaptor not plugged in

#6 2017-05-15 10:53:30

Re: wpa_supplicant@wifi stalling boot if adaptor not plugged in

#7 2017-05-15 12:23:35

Re: wpa_supplicant@wifi stalling boot if adaptor not plugged in

#8 2017-05-15 12:25:21

Re: wpa_supplicant@wifi stalling boot if adaptor not plugged in

#9 2017-05-15 12:50:33

Re: wpa_supplicant@wifi stalling boot if adaptor not plugged in

#10 2017-05-15 13:09:11

Re: wpa_supplicant@wifi stalling boot if adaptor not plugged in

#11 2017-05-15 13:42:47

Re: wpa_supplicant@wifi stalling boot if adaptor not plugged in

#12 2017-05-15 14:20:47

Re: wpa_supplicant@wifi stalling boot if adaptor not plugged in

Board footer