* Atri Bhattacharya [09-13-20 09:09]:

On Sun, 2020-09-13 at 18:01 +0930, Rodney Baker wrote:

...

Sorry, the correct message is "A Stop Job is running for User Manager for UID .

On my desktop I had a similar problem which I tracked down to lvm2- monitor.service begin too slow to quit. Since my system wasn't using LVM disks anyway, I turned that service off and that was that.

Please check if `systemctl status lvm2-monitor` shows "active". If it does, and you don't have an lvm2 disk setup, you can turn it off too `sudo systemctl disable --now lvm2-monitor`. If that helps in your case, it is https://bugzilla.opensuse.org/1129476 or one of its duplicates.

I see the same delay "Stop Job running" frequently on Tw and have for quite some time, ?? year. and disabling lvm2-monitor is not possible as I have no *lvm2* packages installed. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

On Sunday, 13 September 2020 23:36:27 ACST Rodney Baker wrote:

On Sunday, 13 September 2020 22:38:03 ACST Atri Bhattacharya wrote:

...

On Sun, 2020-09-13 at 18:01 +0930, Rodney Baker wrote:

...

Sorry, the correct message is "A Stop Job is running for User Manager for UID .

On my desktop I had a similar problem which I tracked down to lvm2- monitor.service begin too slow to quit. Since my system wasn't using LVM disks anyway, I turned that service off and that was that.

Please check if `systemctl status lvm2-monitor` shows "active". If it does, and you don't have an lvm2 disk setup, you can turn it off too `sudo systemctl disable --now lvm2-monitor`. If that helps in your case, it is https://bugzilla.opensuse.org/1129476 or one of its duplicates.

Cheers,

Ah, ok, thanks, Atri. Lvm2-monitor service was indeed enabled, but failed (because I have no lvm configuration). I've now disabled it - I"ll see how that goes.

Regards, Rodney.

Nope, that wasn't it. :( -- ============================================================== Rodney Baker VK5ZTV rodney.baker@iinet.net.au CCNA #CSCO12880208 ============================================================== -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

Am Sonntag, 13. September 2020, 10:31:19 CEST schrieb Rodney Baker:

On Sunday, 13 September 2020 17:45:34 ACST Rodney Baker wrote:

...

Hi all,

For some time I've been seeing shutdown delays of up to 2min 30 sec on Tumbleweed. The system reports, "A stop job is running for /run/user/ min:sec (counting down)", where min:sec can be anywhere up to 2-3 minutes.

...

How should I go about debugging this? So far, I don't even have enough information to raise a useful bug report (if one is even justified, given that it could be a local config issue rather than something systemic with Tumbleweed).

Regards, Rodney.

Sorry, the correct message is "A Stop Job is running for User Manager for UID .

I am not too familiar with debugging systemd related issues myself. But I stumbled over the following wiki: https://freedesktop.org/wiki/Software/systemd/Debugging/#index2h1 It might be worth a try, even if the last edit to the article has been made in late 2017. Maybe this still works. hth Thomas -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

* Rodney Baker [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. -- (paka)Patrick Shanahan Plainfield, Indiana, USA @ptilopteri http://en.opensuse.org openSUSE Community Member facebook/ptilopteri Photos: http://wahoo.no-ip.org/piwigo paka @ IRCnet freenode -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

On Mon, Sep 14, 2020, 06:54 Patrick Shanahan wrote:

...

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,

...

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

...

network was shut down before all network shares were closed, resulting in those processes timing out trying to close files. It was supposedly

* Rodney Baker [09-14-20 09:50]: [...] then the 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.

On Monday, 14 September 2020 00:45:30 BST Simon Lees wrote:

On 9/13/20 5:45 PM, Rodney Baker wrote:

...

Hi all,

snip

It may not be a bug, openSUSE is configured so that when you log out graphically any background tasks and programs that you have running will remain running. This is useful for people who use screen etc and keep background processes running, however if you want to make sure that when someone logs out any of there remaining processes are killed you can set KillUserProcesses=yes in /etc/systemd/logind.conf This may be a quick and easy way of resolving the issue.

Thanks for that tip. I use 4 logins for different activities and each logout meant it left a few processes around for that user, changing that setting has cleared a lot of processes from the old logins. -- opensuse:tumbleweed:20200910 Qt: 5.15.0 KDE Frameworks: 5.73.0 - KDE Plasma: 5.19.5 - kwin 5.19.5 kmail2 5.15.1 (20.08.1) - akonadiserver 5.15.1 (20.08.1) - Kernel: 5.8.7-1-default - xf86-video-nouveau: 1.0.16 -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

On Tuesday, 15 September 2020 1:37:15 ACST Peter Suetterlin wrote:

Rodney Baker wrote:

...

Hi all,

For some time I've been seeing shutdown delays of up to 2min 30 sec on Tumbleweed. The system reports, "A stop job is running for /run/user/ min:sec (counting down)", where min:sec can be anywhere up to 2-3 minutes. Yeah, have seen that (too) many times. Same if somewhere someone was logged in in one of the virtual screens.

My pragmatic approach is to have

DefaultTimeoutStopSec=10s

in /etc/systemd/system.conf

Thanks, Peter. I also see in /usr/lib/systemd/system/user@.service, a line that says, "TimeoutStopSec=120s". I've changed that to 10s too - I'll see how that goes. Interestingly, this .service file has an ExecStart line but no ExecStop (while other services have both). I don't know if that's signficant or not. I don't know enough about systemd service definitions to make that call. Regards, Rodney. -- ============================================================== Rodney Baker VK5ZTV rodney.baker@iinet.net.au CCNA #CSCO12880208 ============================================================== -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org

On 9/19/20 6:07 PM, Rodney Baker wrote:

On Tuesday, 15 September 2020 23:40:10 ACST Rodney Baker wrote:

...

On Tuesday, 15 September 2020 1:37:15 ACST Peter Suetterlin wrote:

...

Rodney Baker wrote:

...

Hi all,

For some time I've been seeing shutdown delays of up to 2min 30 sec on Tumbleweed. The system reports, "A stop job is running for /run/user/ min:sec (counting down)", where min:sec can be anywhere up to 2-3 minutes.

Yeah, have seen that (too) many times. Same if somewhere someone was logged in in one of the virtual screens.

My pragmatic approach is to have

DefaultTimeoutStopSec=10s

in /etc/systemd/system.conf

Thanks, Peter. I also see in /usr/lib/systemd/system/user@.service, a line that says, "TimeoutStopSec=120s".

I've changed that to 10s too - I'll see how that goes. Interestingly, this .service file has an ExecStart line but no ExecStop (while other services have both). I don't know if that's signficant or not. I don't know enough about systemd service definitions to make that call.

Regards, Rodney.

So, yes, changing TimeoutStopSec in /usr/lib/systemd/system/user@service from 120s to 10s seems to have helped significantly. Since that change, the maximum wait time I've seen shutting down is 13secs, which is a lot better than 2-3 minutes.

I don't know what is the relationship between DefaultTimeoutStopSec in /etc/ systemd/system.conf and TimeoutStopSec in user@service, but it's now down to what I would consider acceptable levels.

The next question therefore is, should I copy the customised /user/lib/ systemd/system/user@service to /etc/systemd/system? As I understand the new paradigm, the system default files should stay in /usr/lib/systemd/... with local customised files under /etc/systemd/... (which won't be overwritten during an update, whereas files under /usr/lib/systemd/ most likely will be).

Is that correct?

My understanding is you should just have your changes from default in your file in /etc/systemd that way if one of the other param's changes in the future due to a new feature etc you will still automatically get those changes. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B

On 9/22/20 9:45 PM, Rodney Baker wrote:

On Monday, 21 September 2020 9:39:29 ACST Simon Lees wrote:

...

On 9/19/20 6:07 PM, Rodney Baker wrote:

...

On Tuesday, 15 September 2020 23:40:10 ACST Rodney Baker wrote:

...

On Tuesday, 15 September 2020 1:37:15 ACST Peter Suetterlin wrote:

...

Rodney Baker wrote:

...

Hi all,

For some time I've been seeing shutdown delays of up to 2min 30 sec on Tumbleweed. The system reports, "A stop job is running for /run/user/ min:sec (counting down)", where min:sec can be anywhere up to 2-3 minutes.

Yeah, have seen that (too) many times. Same if somewhere someone was logged in in one of the virtual screens.

My pragmatic approach is to have

DefaultTimeoutStopSec=10s

in /etc/systemd/system.conf

Thanks, Peter. I also see in /usr/lib/systemd/system/user@.service, a line that says, "TimeoutStopSec=120s".

I've changed that to 10s too - I'll see how that goes. Interestingly, this .service file has an ExecStart line but no ExecStop (while other services have both). I don't know if that's signficant or not. I don't know enough about systemd service definitions to make that call.

Regards, Rodney.

So, yes, changing TimeoutStopSec in /usr/lib/systemd/system/user@service from 120s to 10s seems to have helped significantly. Since that change, the maximum wait time I've seen shutting down is 13secs, which is a lot better than 2-3 minutes.

I don't know what is the relationship between DefaultTimeoutStopSec in /etc/ systemd/system.conf and TimeoutStopSec in user@service, but it's now down to what I would consider acceptable levels.

The next question therefore is, should I copy the customised /user/lib/ systemd/system/user@service to /etc/systemd/system? As I understand the new paradigm, the system default files should stay in /usr/lib/systemd/... with local customised files under /etc/systemd/... (which won't be overwritten during an update, whereas files under /usr/lib/systemd/ most likely will be).

Is that correct?

My understanding is you should just have your changes from default in your file in /etc/systemd that way if one of the other param's changes in the future due to a new feature etc you will still automatically get those changes.

OK, thanks, Simon. BTW, I note you live near Adelaide. So do I - Mt Compass (just down the road). :)

Yeah I noticed the Australian callsign in your sig, I'm in Reynella just off the expressway so it is pretty much just down the road. I have family on the south coast so I go through Mt Compass a few times a month. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B