I see. The reason why your approach works is that shutdown order is the reverse of startup order in systemd.
So if you make you mount unit specify After=wpa_supplicant.service then during shutdown the reverse happens - your mount service will be stopped (unmounted) before wpa_supplicant.service is stopped, eg wifi gets disconnected. This reverse ordering is how you control the order of system services being shut down.
If this works for you reliably it confirms that it is wpa_supplicant’s service ordering that is the issue and we can try to work out a more general fix for it. I’ll have a think about it and see if I can see a clean, simple solution.
Does it still work if you only add wpa_supplicant.service to the After line and not the Wants line ?
Well looking at the pictures again it’s quite clear that the network is torn down afterwards but yes the first entry being shutdown is WPA which most likely is the issue as you already thought.
Do not add a Wants entry. Save and reboot. Verify that the problem is fixed again and that you can’t see any side effects. If this works we’ll include it in the next update.
It should work because it should enforce this shutdown order:
Shutdown mount units (which are After=network.target)
Shutdown connman (bringing the network down at the IP level)
Shutdown wpa_supplicant (bring down wifi)
Previously the shutdown of 3 would have been asynchronous to the other two and might happen first depending on timing.
@DBMandrake
I assume for my default setup I just would change that line, nothing else to do, or?
Will try to remotely test (need to judge on how fast ssh comes up again).
If ssh is through wifi, I wouldn’t expect any difference. Thinking a bit further, with the suggestion I just made, presumably all networking is stalled until wifi comes up. I can see some dangers, there, actually. I would be happier if only the shares using wifi waited for wpa_supplicant. Other things like ssh, updating the clock or booting via nfs(!) shouldn’t have to wait if they are hard-wired.
Good memory you have but moved away from the NFS boot since 1-2 months so that would not impact. Anyhow would not do that on WIFI that was on wired.
Anyhow I will test this later when back home an knowing why it didn’t come to live after reboot.
Got that, but the machine I made the change is Wifi based. Anyhow let’s not spend time on speculation. I will check as soon as I am physical at the boxes.
Will first check the Wifi only machine and then the Wired only machine.
@DBMandrake@grahamh
I can confirm adding that line fixed the waiting for unmount on the wifi connected box and has not brought any bad side effects on the machine connected wired.
(Just FYI the box not starting after reboot was a strange thing it hanging at “Store Sound Card State”
No, it won’t stall anything until Wifi comes up. It will only wait for wpa_supplicant to start, not for a wifi connection to be established. wpa_supplicant is a daemon that is running on any system with wifi hardware enabled. Normally it would take something like a second for the service to start regardless of whether wifi is configured to connect to a network or not.
Also, using After= (and not Wants=) will only wait for wpa_supplicant if it is already scheduled to start in the same systemd transaction, otherwise there is no additional delay. So if there is no wifi hardware wpa_supplicant will not be scheduled to start so there is nothing to wait for. If there is wifi hardware and wpa_supplicant is scheduled to start in the same transaction as connman it will make sure it does so before connman.
Running systemd-analyze plot >plot.svg both with and without the change on systems with and without wifi should confirm this.
There will be very little effect on the startup - because it’s dbus activated it’s possible that wpa_supplicant doesn’t even start during the same transaction as connman anyway and that it only starts after a hardware scan detects wifi hardware (udev rule scan) in which case the After= won’t have any real effect during boot.
However regardless of how wpa_supplicant is started or when, it will have the desired effect of reverse ordering on shutdown and making sure wpa_supplicant is shut down after connman and (indirectly) after mount units.
I think it will be fine, but it’s always good to test each scenario to be sure.
Ah, so that explains why I could not get the mount to work unless I also invoked wait for network (in MyOSMC) or used automount. All is now crystal clear, including why automount is better than just waiting for connman-wait-for-network.
And I don’t see any reason to change the advice in the OP. The Wants may be superfluous if already wanted by other units but no harm done.
so will wait till I have physical access.