NFS shutdown stop job delay on wireless, fast shutdown on wired connection

[brunomcl]

New install on laptop, KDE. Seven NFS entries in fstab:

192.168.1.1:/home/shares/Gravados/Publico   /home/laptop/Shares/Publico   nfs      noauto,users                    0  0
192.168.1.1:/home/shares/Gravados/Desenhos  /home/laptop/Shares/Desenhos  nfs      noauto,users                    0  0
192.168.1.1:/home/shares/Gravados/Series    /home/laptop/Shares/Series    nfs      noauto,users                    0  0
192.168.1.1:/home/shares/Gravados/Filmes    /home/laptop/Shares/Filmes    nfs      noauto,users                    0  0
192.168.1.1:/home/shares/Gravados/Filmes_2  /home/laptop/Shares/Filmes_2  nfs      noauto,users                    0  0
192.168.1.1:/home/shares/Gravados/Shows     /home/laptop/Shares/Shows     nfs      noauto,users                    0  0
192.168.1.1:/home/shares/Gravados/Series_2  /home/laptop/Shares/Series_2  nfs      noauto,users                    0  0

On wired connection shutdown is normal. With wireless connection there’s a 1m30s stop job delay for the /home/laptop/Shares/Series NFS share, although probably it’s also waiting for the other shares timeout.

So apparently wireless is shut down before shares, but not ethernet.

FWIW, there are other four wired boxes accessing these shares that shut down normally.

In one of them I have used the following nfs options, the others are the same as the laptop:

soft,noauto,rw,users,timeo=100,retrans=2  0  0

This should reduce the delay if the server is down, but as it runs practically 24 x 7 it’s been a long time and I don’t recall the circumstances. I’ve also read that using the timeout/retrans options with soft may lead to corruption, but only Publico is rw (and only occasionally used ), all others are ro.

Any idea on how to fix this shutdown delay?

Thanks

[knurpht]

Since user ‘laptop’ mounts the shares manually AFAICS, you could write a simple bash script that unmounts the shares and add that to systemsettings’ autostart. After adding the script, you can set it to run on logout.

[tsu2]

I’d imagine the simplest approach would be to manually and if necessary forcibly unmount your NFS shares before executing your shutdown… Otherwise I’ve seen it pretty common for shutdowns to simply apply a “wait…” for some specified amount of time guessing whether whatever is causing the delay has become inactive (another common scenario are database client/server connections).

Although I’d expect that it would be more elegant to do something like write a Unit file that contains the unmount commands or calls an unmount script and make that a requirement of a shutdown… or doing something similar to that in the code and configuration for the specific Desktop you’re running…

A quick and dirty approach which should also work is to simply create a new shutdown script that contains your mount commands and ends with shutting down your system with either a “systemctl poweroff” or hooks into your Dekstop shutdown.
Then, execute your script to shutdown instead of the usual…
This script would shutdown much more quickly by eliminating the guestimating waits and pro-actively do what is necessary before finally issueing the shutdown command.

Remember that a successful and safe unmount requires zero data transfer activity.
Forced unmounts may be necessary at times if the connection is left “open,” if you’re absolutely sure no data is being transferred then you can over-ride safeguards, but if there are any unfinished writes still on the fly, then you will likely end up with corruption.

IMO,
TSU

[brunomcl]

@Knurpht

Since user ‘laptop’ mounts the shares manually AFAICS, you could write a simple bash script that unmounts the shares and add that to systemsettings’ autostart. After adding the script, you can set it to run on logout.

Yes, but there are two possible issues:

1. The shares are indeed mounted manually, so if they are not, will the umount script also timeout waiting for the a mounted share to appear? One workaround would be to force mount and umount is the shutdown script, but if then the server is not accessible there would be mount timeouts, I suppose, going back to the same problem.

2. The problem is not to umount the shares in shutdown, it is to umount with a wifi connection, given that it works with wired.
   That’s what puzzles me: why is the wireless connection shutdown before a wired one, it that’s what’s happening? A systemd thing?

Not being able to solve issue 2 above, an alternative is to reduce the timeout duration.

[brunomcl]

@tsu2

I’d imagine the simplest approach would be to manually and if necessary forcibly unmount your NFS shares before executing your shutdown… Otherwise I’ve seen it pretty common for shutdowns to simply apply a “wait…” for some specified amount of time guessing whether whatever is causing the delay has become inactive (another common scenario are database client/server connections).

There’s no wait on a wired connection (given that the server is OK), it only happens over wifi. That’s the issue.
Also the user (not me) will probably forget to run the umount script manually most of the time, or else forget which shares are mounted and which are not.

@tsu2

Although I’d expect that it would be more elegant to do something like write a Unit file that contains the unmount commands or calls an unmount script and make that a requirement of a shutdown… or doing something similar to that in the code and configuration for the specific Desktop you’re running…

That would work if it checked before what is mounted and what isn’t, without the check timing out. I’m afraid writing systemd units are a bit over here.

@tsu2

A quick and dirty approach which should also work is to simply create a new shutdown script that contains your mount commands and ends with shutting down your system with either a “systemctl poweroff” or hooks into your Dekstop shutdown.
Then, execute your script to shutdown instead of the usual…
This script would shutdown much more quickly by eliminating the guestimating waits and pro-actively do what is necessary before finally issueing the shutdown command.

See issue 1 in my previous post. It would probably still timeout.

@tsu2

Remember that a successful and safe unmount requires zero data transfer activity.
Forced unmounts may be necessary at times if the connection is left “open,” if you’re absolutely sure no data is being transferred then you can over-ride safeguards, but if there are any unfinished writes still on the fly, then you will likely end up with corruption.

IMO,
TSU

That shouldn’t be an issue given the way the writable share is used.

[brunomcl]

@brunomcl

On wired connection shutdown is normal. With wireless connection there’s a 1m30s stop job delay for the /home/laptop/Shares/Series NFS share, although probably it’s also waiting for the other shares timeout.

I’m curious about the shutdown delay message for share Series only. I’ve already seen multiple delay messages, probably on startup when the NFS server is off, so I’d suppose there should be the same multiple delays in shutdown, not only one.

However, all export options are the same as for Series, except for one rw:

:~> cat /etc/exports
/home/shares/Gravados/Publico    *(rw,root_squash,sync,no_subtree_check)
/home/shares/Gravados/Desenhos    *(ro,all_squash,sync,no_subtree_check)
/home/shares/Gravados/Filmes    *(ro,root_squash,sync,no_subtree_check)
/home/shares/Gravados/Filmes_2    *(ro,root_squash,sync,no_subtree_check)
/home/shares/Gravados/Series    *(ro,root_squash,sync,no_subtree_check)
/home/shares/Gravados/Series_2    *(ro,root_squash,sync,no_subtree_check)
/home/shares/Gravados/Shows    *(ro,root_squash,sync,no_subtree_check)
:~> 

Is there an icon for head scratching?

[knurpht]

Another thing that might help, is setting the Network connection to “Available for all users” ( requires root password ), and in the Security tab to store the password unencrypted. IIRC the connection will stop/start after/before user login.

[tsu2]

Any solution that works for both wired and wireless should be acceptable, it’s not like whatever happens that works for wireless should seriously affect a wired connection shutdown adversely.

Writing systemd Units can be very easy even if you haven’t done anything of the sort before.
You’d need some very minor background looking at commands, or be willing to try to make intuitive sense of commands you haven’t seen before.
Don’t ever create a systemd Unit file from scratch on your own, a fundamental skill in any kind of coding is to copy everything you can from working examples. So, the first step is to skim through a number of random, existing Unit files on your system looking for something that’s already close to what you want to accomplish. In your case, you’d be looking for something that’s pretty simple… execute a command or a script elsewhere on the system.
Following systemd good practices (You’ll want to learn the 3 or so main rules for Best Practices), copy and rename the Unit file you’ve found, then edit it as necessary.
Test, and modify if it doesn’t work right away.
If you end up wanting to return your system to before your Unit file attempts, just delete the Unit file you’re working on… Because you copied and created your own Unit file, it’s that easy to return your system to before… Just delete your file. That’s one of the best pracices, don’t ever alter an original systemd Unit file, only work with copies you can simply delete to undo.

As for your unmounts…
It should not ever matter how the share was originally mounted, only that there’s no activity.
If there activity, then your unmount will be delayed and possibly eventually fail (which is actually good since it won’t result in corrupted data)
Just don’t <force> an unmount unless you’re confident you aren’t in the middle of a data write.
Depending on how you mount your shares, you should be able to unmount all your shares without naming your shares individually.

HTH,
TSU

[arvidjaar]

@brunomcl

Any idea on how to fix this shutdown delay?

Most likely you are using NetworkManager with user connections (where wireless secrets are provided by agents run as part of user session), in which case user sessions are terminated and interface is down before filesystems are unmounted. If I am right, the most obvious way is to use system connections (may be called “Available to all users” in your variant of NetworkManager frontend) that are stopped at the same time as wired ones, so normally after filesystems have been unmounted

[knurpht]

@arvidjaar

Most likely you are using NetworkManager with user connections (where wireless secrets are provided by agents run as part of user session), in which case user sessions are terminated and interface is down before filesystems are unmounted. If I am right, the most obvious way is to use system connections (may be called “Available to all users” in your variant of NetworkManager frontend) that are stopped at the same time as wired ones, so normally after filesystems have been unmounted

That’s what I meant, and now have tested:

• Router has two AP’s, 2.4 and 5.0 GHz, different SSIDs.
• Rpi has 1 NFS export
• Laptop has one fstab entry, with ‘noauto, users’
• 2.4 connection is user only, shutdown hangs ( for ~3 minutes )
• 5.0 connection is ‘Available for all users’ ( so in arvidjaar’s words a system connection ), nfs share gets properly unmounted at shutdown. No delay.
• Changed connections vice versa to make sure frequency was not interfering, result was v.v. as well.

[brunomcl]

@Knurpht

Another thing that might help, is setting the Network connection to “Available for all users” ( requires root password ), and in the Security tab to store the password unencrypted. IIRC the connection will stop/start after/before user login.

Knurpht, that fixed it, you’re the man! Thank you very much indeed.

Also thanks to arvidjaar and tsu for replying.

Best regards,

Bruno