[opensuse-support] Slow shutdown - "stop job running for /run/user/<user_id>"
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/<user_id> min:sec (counting down)", where min:sec can be anywhere up to 2-3 minutes. Once this timer runs down, shutdown proceeds as normal. If I log out of the desktop session first, then log into a VTY session as root and enter "Poweroff", shutdown takes less than 10 seconds. My guess is that there is a race condition going on with some process still holding a file open in /run/user/<user_id> (whcih is a tmpfs file system, when the system is attempting to destroy it, but I have been so far completely unsuccessful in identifying what that could be. I've even tried enabling a debug terminal session on VTY9 but that's given no clue, either. 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. -- ============================================================== 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 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/<user_id> min:sec (counting down)", where min:sec can be anywhere up to 2-3 minutes.
Once this timer runs down, shutdown proceeds as normal. If I log out of the desktop session first, then log into a VTY session as root and enter "Poweroff", shutdown takes less than 10 seconds.
My guess is that there is a race condition going on with some process still holding a file open in /run/user/<user_id> (whcih is a tmpfs file system, when the system is attempting to destroy it, but I have been so far completely unsuccessful in identifying what that could be. I've even tried enabling a debug terminal session on VTY9 but that's given no clue, either.
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 <User_ID>. -- ============================================================== 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 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 <User_ID>.
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, -- Atri Bhattacharya Sun 13 Sep 14:58:44 CEST 2020 Sent from openSUSE Tumbleweed on my laptop. -- To unsubscribe, e-mail: opensuse-support+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-support+owner@opensuse.org
* Atri Bhattacharya <badshah400@opensuse.org> [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 <User_ID>.
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 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 <User_ID>.
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. -- ============================================================== 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 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 <User_ID>.
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 13.09.20 um 10:31 schrieb Rodney Baker:
On Sunday, 13 September 2020 17:45:34 ACST Rodney Baker wrote:
Sorry, the correct message is "A Stop Job is running for User Manager for UID <User_ID>.
Same problem here tumbleweed, as you wrote since about a year i think..... here with nfs and not used lvm simoN -- www.becherer.de -- 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/<user_id> 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 <User_ID>.
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
On 13/09/2020 10.15, 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/<user_id> min:sec (counting down)", where min:sec can be anywhere up to 2-3 minutes.
Once this timer runs down, shutdown proceeds as normal. If I log out of the desktop session first, then log into a VTY session as root and enter "Poweroff", shutdown takes less than 10 seconds.
My guess is that there is a race condition going on with some process still holding a file open in /run/user/<user_id> (whcih is a tmpfs file system, when the system is attempting to destroy it, but I have been so far completely unsuccessful in identifying what that could be. I've even tried enabling a debug terminal session on VTY9 but that's given no clue, either.
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).
I have, not always but occasionally, perhaps a related issue in Leap 15.1. I command hibernate, by calling "sudo /usr/bin/systemctl hibernate". After a while I come back to power off the UPS, and see the machine still running. I try repeating the hibernate order, sometimes it works. Other times it doesn't, says there is an hibernate in progress. I command a shutdown with poweroff, which also gets stuck. I press rapidly several "ctrl-alt-supr", and I get a message that the key sequence was detected more than seven times in two seconds, rebooting fast. It does not. In the end, I have to remove the power cord. The last time, this resulted in a damaged disk. Never it says what is holding it, there are no messages in the log or screen. :-/ -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
As you say, something seems to have file open in /tmp. If you have access to a terminal try fuser to find what user/process has some file open in /tmp. Tomas
* Tomas Kuchta <tomas.kuchta.lists@gmail.com> [09-13-20 15:50]:
As you say, something seems to have file open in /tmp.
If you have access to a terminal try fuser to find what user/process has some file open in /tmp.
when I see the msg displayed, there is no access to the machine. -- (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 9/13/20 5:45 PM, 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/<user_id> min:sec (counting down)", where min:sec can be anywhere up to 2-3 minutes.
Once this timer runs down, shutdown proceeds as normal. If I log out of the desktop session first, then log into a VTY session as root and enter "Poweroff", shutdown takes less than 10 seconds.
My guess is that there is a race condition going on with some process still holding a file open in /run/user/<user_id> (whcih is a tmpfs file system, when the system is attempting to destroy it, but I have been so far completely unsuccessful in identifying what that could be. I've even tried enabling a debug terminal session on VTY9 but that's given no clue, either.
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).
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. -- 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 Monday, 14 September 2020 9:15:30 ACST Simon Lees wrote:
On 9/13/20 5:45 PM, 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/<user_id> min:sec (counting down)", where min:sec can be anywhere up to 2-3 minutes.
Once this timer runs down, shutdown proceeds as normal. If I log out of the desktop session first, then log into a VTY session as root and enter "Poweroff", shutdown takes less than 10 seconds.
My guess is that there is a race condition going on with some process still holding a file open in /run/user/<user_id> (whcih is a tmpfs file system, when the system is attempting to destroy it, but I have been so far completely unsuccessful in identifying what that could be. I've even tried enabling a debug terminal session on VTY9 but that's given no clue, either.
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).
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, 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. I did do an "lsof | grep '/run/user'" while that stop job was running last time I shut it down, and noted that Pulse Audio and a couple of other processes still had files open in /run/user/<user-id>, but I don't know if that's significant or not. Running lsof with no parameters showed a whole stack of fles still open, but I don't really know which ones are significant or not at that stage of the shutdown process. I guess I could check all of those owned by my user, but would that be useful? -- ============================================================== 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
* 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. -- (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 Monday, 14 September 2020 23:24:23 ACST Patrick Shanahan wrote:
* 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.
Whereas I see it every time I shut down (but no remote shares of any kind mounted). -- ============================================================== 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 Mon, Sep 14, 2020, 06:54 Patrick Shanahan <paka@opensuse.org> 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 <rodney.baker@iinet.net.au> [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.
... snip ...
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.
This would not help if the process accessing the disk is not owned by the user - such as service/daemon/userByCron/isForked/etc.
I've set KillUserProcesses=yes in /etc/systemd/logind.conf and rebooted, then tested again, but with the same result.
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
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/<user_id> 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 -- 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/<user_id> 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 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/<user_id> 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? -- ============================================================== 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/<user_id> 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 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/<user_id> 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). :) 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/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/<user_id> 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
participants (10)
-
Atri Bhattacharya -
Carlos E. R. -
Ianseeks -
Patrick Shanahan -
Peter Suetterlin -
Rodney Baker -
Simon Becherer -
Simon Lees -
Thomas Rosenberger -
Tomas Kuchta