<div dir="ltr"><div dir="ltr"><div dir="ltr">On Fri, Apr 5, 2019 at 9:28 AM Harald Dunkel <<a href="mailto:harald.dunkel@aixigo.de">harald.dunkel@aixigo.de</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi folks,<br>
<br>
I've got a device-busy-problem with /home, mounted via NFS.<br>
Shutdown of the host takes more than 180 secs. See attached<br>
log file.<br>
<br>
Apparently the umount of /home at 81925.154995 failed, (device<br>
busy, in my case it was a lost gpg-agent). This error was<br>
ignored, the NFS framework was shut down, the network was<br>
stopped, and then it was too late to properly handle the /home<br>
mount point.<br>
<br>
AFAIK the mount units are generated from /etc/fstab, so I wonder<br>
if this could be improved?<br></blockquote><div><br></div><div>The job order (home.mount vs nfs-client.target) already looks correct, so fstab options probably won't help much; I'd try to ensure that the umount doesn't fail in the first place.</div><div><br></div><div>Normally I'd expect user sessions (user-*.slice, session-*.scope, user@*.service) to be killed before mount units are stopped; I wonder how random gpg-agent processes have managed to escape that. (Actually, doesn't Debian now manage gpg-agent via user@.service? That *really* should be cleaning up everything properly...)</div><div><br></div><div>You might also try to enable [Mount] LazyUnmount= for home.mount so that umounts appear to succeed immediately and the kernel cleans them up when it can. It mostly just hides the problem though.</div></div><div><br></div>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr">Mantas Mikulėnas</div></div></div></div>