* Rodney Baker <rodney.baker@iinet.net.au> [09-14-20 09:50]:
[...]
> Thanks, Simon, but that didn't fix it (see the correction I posted further up
> the thread re the error message: it's actually "A Stop Job is running for User
> Manager for UID <user-id>".
>
> I've set KillUserProcesses=yes in /etc/systemd/logind.conf and rebooted, then
> tested again, but with the same result.
>
> This previously happened somewhere in a previous version, in the early days of
> the 'wicked' network daemon; the issue then was a race condition where the
> network was shut down before all network shares were closed, resulting in
> those processes timing out trying to close files. It was supposedly primarily
> related to nfs shares, but I've never had nfs shares mounted on this machine.
> Whatever was done to fix that did fix the problem for me back then.
>
> That's what makes me think that this might be a similar situation - a race
> condition involving a process timing out because a dependency is terminated
> first, but I have no clue as to exactly what that dependency is. It might be a
> simple matter of editing a systemd unit file or two to make sure that
> processes shut down in the correct order. I'd love to help debug it, if only I
> knew what to do.
fwiw: I do have nfs shares mounted ...
but only see the "Stop Job running" message occasionally and canoot define
a pattern.
.
I get that with NFS when the server's disks are sleeping or I accidentally shut nfs server down.
For a while I suspected that network by networManager was causing it because the network was down before nfs sync/umount. While that maybe true, occasionally, I found human at play more often than not. I also converted NFS mounts to autofs - which further lowers the chance of having nfs mounted at shutdowns.