Well, when I added a new dedicated NAS with a btrfs RAID, I added an NFS mount to the drive for convenience from my desktop pc. Shutdowns seemed to be taking considerably longer and I narrowed it down (using the journal) to the nfs mount/unmount. Certainly not mounting it fixes the problem, but umm I want it mounted lol.
I think the problem is the wireless network is/was already gone when I get to that point in the shutdown, I’ve researched some on the arch-wiki and older posts, and added the bit in /etc/fstab that indicates network is still required to for this..and that’s successful, Network Manager doesn’t exit till after the nfs mount is unmounted. Still it seems that I don’t quite understand something. You’ll notice a ten second wait before the NFS mount is unmounted…that is something I’d like to understand and fix. Of note is that if I unmount manually while not shutting down, it’s normal and instantaneous.
What am I missing…here’s a journal log and then I’ll share my /etc/fstab line below.
May 27 04:40:34 desktop-x8664 systemd[1]: ananicy-cpp.service: Deactivated successfully.
May 27 04:40:34 desktop-x8664 systemd[1]: Stopped Ananicy-Cpp - ANother Auto NICe daemon in C++.
May 27 04:40:44 desktop-x8664 systemd[1]: mnt-raid.mount: Unmounting timed out. Terminating.
May 27 04:40:44 desktop-x8664 systemd[1]: mnt-raid.mount: Mount process exited, code=killed, status=15/TERM
May 27 04:40:44 desktop-x8664 systemd[1]: mnt-raid.mount: Failed with result 'timeout'.
May 27 04:40:44 desktop-x8664 systemd[1]: mnt-raid.mount: Unit process 8550 (umount.nfs4) remains running after unit stopped.
May 27 04:40:44 desktop-x8664 systemd[1]: Unmounted /mnt/raid.
May 27 04:40:44 desktop-x8664 systemd[1]: Stopped target Network is Online.
May 27 04:40:44 desktop-x8664 systemd[1]: Stopped target Network.
May 27 04:40:44 desktop-x8664 systemd[1]: NetworkManager-wait-online.service: Deactivated successfully.
May 27 04:40:44 desktop-x8664 systemd[1]: Stopped Network Manager Wait Online.
May 27 04:40:44 desktop-x8664 systemd[1]: Stopping Network Manager...
May 27 04:40:44 desktop-x8664 NetworkManager[1176]: <info> [1748338848.7373] caught SIGTERM, shutting down normally.
May 27 04:40:44 desktop-x8664 systemd[1]: Stopping Wireless service...
May 27 04:40:44 desktop-x8664 iwd[1226]: Terminate
May 27 04:40:44 desktop-x8664 iwd[1226]: Removing scan context for wdev 2
May 27 04:40:44 desktop-x8664 systemd[1]: Stopping WPA supplicant...
May 27 04:40:44 desktop-x8664 systemd[1]: wpa_supplicant.service: Deactivated successfully.
May 27 04:40:44 desktop=x8664 systemd[1]: Stopped WPA supplicant.
Syncing is usually “it”, since Linux keeps a lot of stuff in RAM which has to be synced upon unmounting.
Also, file managers tend to do a lot of accessing (wanting to know free space etc.), so if you have, per chance, not mounted your share using noatime and nodiratime, writing back all the last access times to folders and files can also take some additional time. Especially over slow connections, say WiFi “on the road”, over a low-MTU VPN.
Just to show I’m not totally crazy (well maybe), proof of interactive behavior:
May 27 06:26:17 desktop-x8664 sudo[10950]: dbarron : TTY=pts/0 ; PWD=/home/dbarron/Pictures/Screenshots ; USER=root ; COMMAND=/usr/bin/umount /mnt/raid
May 27 06:26:17 desktop-x8664 sudo[10950]: pam_unix(sudo:session): session opened for user root(uid=0) by dbarron(uid=1000)
May 27 06:26:17 desktop-x8664 systemd[1]: mnt-raid.mount: Deactivated successfully.
May 27 06:26:17 desktop-x8664 sudo[10950]: pam_unix(sudo:session): session closed for user root
Yeah, I don’t think it’s dirty. Nothing should be using it. No more than using it when I manually unmount it, for sure.
Plus I think if it were dirty, it would finish it’s sync vs terminate.
I only (while trying to troubleshoot this) added the timeouts to /etc/fstab, it was originally a hard mount (with no time outs)…and behavior/logging was the same.
mei 27 15:07:19 afk20ce systemd[1]: SSD2TB.mount: Deactivated successfully.
mei 27 15:07:19 afk20ce systemd[1]: SSD2TB.automount: Got hangup/error on autofs pipe from kernel. Likely our automount point has been unmounted by someone or something else?
mei 27 15:07:19 afk20ce systemd[1]: SSD2TB.automount: Failed with result 'unmounted'.
There seems to be some contention between auto(un)mount and manual unmount?
My interpretation of your error is that the mount point got unmounted before the NFS mount?
Which is different than mine…but also kinda weird (since you’d expect a network mount to go before a regular filesystem)?
Indeed - weird. Something is fishy, is what I thought.
Perhaps it might indicate that there is something ‘structurally’ not quite right with systemd automount, which could perhaps be a pointer to where to look for your problem?
I suspect maybe because I use _netdev. Excerpt from man systemd.mount:
_netdev
Network mount units are ordered between remote-fs-pre.target and remote-fs.target, instead of local-fs-pre.target and local-fs.target. They also pull in network-online.target and are ordered after it and network.target.
Good suggestion, I think. Worth a try. That’s the parameter I add whenever I find something wrong with mounting or unmounting.
Not sure it would make a difference for the manual unmount vs the automatic unmount.
Came across [1] " [SOLVED] NFS umount delays systemd shutdown or reboot]", where it says:
The mount needs to be specified in fstab with “x-systemd.requires=network-online.target”, not “x-systemd.requires=network.target”. I’ve had no problems since mounting it this way. I changed the wiki page that had the wrong target, and I’m going to mark this solved.
So from that info I think @dbarronoss has the right x-systemd.requires option.
)
