broken [Install] section in wpa_supplicant at .service file?

Patrick Ohly patrick.ohly at intel.com
Fri Mar 10 02:15:56 PST 2017


Hello!

After making some changes to a Yocto-based Linux image I ran into the
sys-subsystem-net-devices-multi-user.device timeout problem. Various
people have reported that, for example here:
https://www.reddit.com/r/archlinux/comments/4mnkyu/timeout_during_boot/?st=j03jwv0d&sh=14c1a955

In my case I traced it down to this combination of circumstances:
      * /etc/machine-id is missing during booting.
      * systemd then auto-enables all system units according to their
        [Install] section because it detects a first-boot scenario.
      * /lib/systemd/system/wpa_supplicant at .service contains
        Alias=multi-user.target.wants/wpa_supplicant@%i.service in its
        [Install] section.
      * That gets turned into a
        symlink: /etc/systemd/system/multi-user.target.wants/wpa_supplicant at .service -> /lib/systemd/system/wpa_supplicant at .service.
      * systemd then seems to replace %i in that service file with
        "multi-user", so multi-user.target ends up depending on
        wpa_supplicant at multi-user.service, which in turn depends on
        sys-subsystem-net-devices-multi-user.device.
      * That multi-user "device" of course never appears -> 90 second
        delay until the unit times out.

The same happens for the other wpa_supplicant*@.service flavors.

This %i was introduced in:
https://w1.fi/cgit/hostap/commit/wpa_supplicant/systemd/wpa_supplicant.service.arg.in?h=hostap_2_6&id=893a0a558cd8fd9a7dc5827f379e0f8a273a4fe5

Apparently the motivation was to get rid of a hard-coded wlan0, but how
was it supposed to work with %i instead? Arend, do you still remember?

There's a bug 477 mentioned in that commit, but that probably was in the
bug tracker which is now gone?

-- 
Best Regards, Patrick Ohly

The content of this message is my personal opinion only and although
I am an employee of Intel, the statements I make here in no way
represent Intel's position on the issue, nor am I authorized to speak
on behalf of Intel on this matter.






More information about the Hostap mailing list