Bug 86707

Sorry forgot muy patch, i was testing with a reboot and not with shutdown. It does not work

Sorry for the inconveniente

Regards

Hi,

I had the same kind of problem with a / filesystem hosted in a file on a NTFS partition (/boot is on an usb key).

Here is how solve it:

https://github.com/koniiiik/oi-live/blob/master/oi-live/ntfs-3g-initrd-wrapper.c

http://0pointer.de/blog/projects/systemd-for-admins-2.html

_netdev mounts already get "network.target" dependency. However, as _netdev is a userspace option, this only works if the file systems are mounted from userspace.

My guess is that wpa_supplicant.service should really have a Before=network.target dependency. Does it have that on your system?

Created attachment 110652 [details]
systemctl-status after boot

Created attachment 110653 [details]
dmesg booting, to know which order and which services are being executed

Created attachment 110654 [details]
Summarize what happens when system try to halt

(In reply to Alexandre Detiste from comment #2)
> Hi,
> 
> I had the same kind of problem with a / filesystem hosted in a file on a
> NTFS partition (/boot is on an usb key).
> 
> Here is how solve it:
> 
> https://github.com/koniiiik/oi-live/blob/master/oi-live/ntfs-3g-initrd-
> wrapper.c
> 
> http://0pointer.de/blog/projects/systemd-for-admins-2.html

Hello Alexandre,

Thank you for pointing your solution.

I think this problem should be solved at wpa_supplicant upstream (if somebody can confirm it happens too outside Debian)

If we are able to solve this issue, I will give this reference bug to wpa_supplicant developpers (seems active people), so they can change its wpa_supplicant.service

Maybe if the problem is not solved soon (weeks?) I will ask to them about this issue at their mail list / bugtracker

Thank you

(In reply to Lennart Poettering from comment #3)
> _netdev mounts already get "network.target" dependency. However, as _netdev
> is a userspace option, this only works if the file systems are mounted from
> userspace.
> 
> My guess is that wpa_supplicant.service should really have a
> Before=network.target dependency. Does it have that on your system?

Hello,

At my (Debian Sid) system wpa_supplicant.service has not such depend.

Seems like at Debian wpa_supplicant.service is not changed from upstream:
http://w1.fi/cgit/hostap/tree/wpa_supplicant/systemd/wpa_supplicant.service.in

I tried to add Before attribute? so it can read:

$ systemctl cat  wpa_supplicant.service 
# /lib/systemd/system/wpa_supplicant.service
[Unit]
Description=WPA supplicant
Before=network.target

[Service]
Type=dbus
BusName=fi.epitest.hostap.WPASupplicant
ExecStart=/sbin/wpa_supplicant -u -s -O /run/wpa_supplicant

[Install]
WantedBy=multi-user.target
Alias=dbus-fi.epitest.hostap.WPASupplicant.service

But it didn't work.

I'm uploading files which I think can help to solve the issue.

At systemctl-status-booting.txt you can see two things:
 - curlftps is a dependency from NetworkManager-dispatcher.service
 - mnt-usb.mount fails the first try (see Process field at systemctl status -f mnt-usb.mount) (Error Connecting to FTP)

At dmesg-booting.txt.gz can be seen dmesg after booting

Finally at halting.txt I try to summarize what happen when system is halting:
 - start umount /mnt/usb
 - wpa_supplicant deauthenticate
 - umount will not finish until it is killed by systemd after a timeout

I really appreciate your help. Please tell me if you need some additional info.

Thank you very much

I'm not sure if I should change status field. Sorry if that field should be only changed by Systemd developpers

In support of the fix per Lennart Poettering in #3, I had a similar issue with my media server failing to exit at shutdown, which I eventually was able to isolate to wpa_supplicant.service having stopped too early. I installed "Before=network.target" (which makes perfect sense to me) via a drop-in for wpa_supplicant.service, and it did, indeed, resolve the issue.

Hello,

I have just send next mail to debian bug tracker system:

=== COMMENT BEGIN ===
What I am see on my Debian Sid system:

1. systemd-fstab-generator generate mnt-usb.mount
2. NetworkManager-dispatcher is really who mount /mnt/usb directory

After I generate a /etc/systemd/system/mnt-usb.mount with an incorrect
syntax, My system shutdown well after a timeout of 10 seconds. I added
Before=network.target to wpa_supplicant.service as indicated at
upstream bugtracker.

I tried to disabling nm-dispatcher (chmod -x), but mnt-usb.mount was
not able to manage to mount (I guess it tries before than the network
is online (a ftp connection error is showed at systemctl status
mnt-usb.mount)

Which is the correct way to make this work ?

How can I disable mnt-usb.mount ? (I think I  tried without success
systemctl mask)

=== COMMENT END ===

Which is the preferred method to use only one service to such mount point (dispatcher or fstab-generator)?

Thank you very much

Note that systemd git is now able to read the _netdev option from userspace for mounts that are done on the shell, without /etc/fstab. With that in place systemd is now able to order all mounts after network.target automatically, regardless if configured in /etc/fstab or done manually, as long as they have _netdev  specified. Then, if wpa_supplicant.service contains After=network.target all should be good. As the shutdown order between two units is always the reverse of the startup order this means the mount units are unmounted first, before wpa_supplicant is terminated.

Hence, closing, everything else needs to be done with the right After=network.target dep in wpa_supplicant.service

Hello,

Can you say in which version start systemd to have such behaviour ?

Thank you
PD: I will forward your comments to wpa_supplicant bug tracker / debian bug tracker

This is fixed in systemd git, will be part of the next systemd release, which is hopefully out within two weeks or so.

(In reply to Lennart Poettering from comment #14)
> This is fixed in systemd git, will be part of the next systemd release,
> which is hopefully out within two weeks or so.

Thank you !

*** Bug 82061 has been marked as a duplicate of this bug. ***

Has someone forwarded the issue to wpasupplicant upstream to get Before=network.target added to wpa_supplicant.service.in?

(In reply to Michael Biebl from comment #17)
> Has someone forwarded the issue to wpasupplicant upstream to get
> Before=network.target added to wpa_supplicant.service.in?
Hello,

I tried to forward, but not body replied:
http://readlist.com/lists/shmoo.com/hostap/3/18622.html

Regards,