Whenever I want to reboot or shutdown Fedora I go through a 45 second timeout process. This isn’t affecting booting the machine.
Like it says in the photo: Job user@1000.service/stop running … .scope/stop running (x/45s)
There’s a little progress animation with asterisks running in the leading brackets left.
I’m pretty sure it’s not there right after an install, but one or other of the steps I take setting up Fedora makes the system wait for something that does not happen within the 45 seconds. It’s not the first time I’ve experienced this.
Try running systemctl --user status (as your normal user) before shutting down to see what all is running in your user session.
Another way might be to tell a Bash shell on a VT to ignore the normal hang-up/terminate signals and leave a sudo journalctl -f command running on that VT and watch events as it is shutting down. Or you could just run that systemctl --user status command to see what processes are not stopped yet.
P.S. I would expect the same stop sequence to happen on logout. So you could probably test by logging out of your user session. That would be easier. Since you can have multiple sign ins, you could watch the first user session shutdown from a second one running on another VT.
Hmm, what I’m suspecting is happening in that case is that the login screen is showing before your user is really signed out. If you sign in on a VT with root, and run systemctl status user-1000.slice after you sign out from your normal user session, I bet you will see that some program is still running in that process tree long after your login screen has appeared.
The virtual terminals are accessed by a hot key. Ctrl+Alt+F3 should work to access VT3. If you have not done so, you will have to set a password on the “root” account before you will be able to sign in with it on a VT. Use sudo passwd root to set a password for the root account.
I found the ctrl-alt-F2 shortcut before I read your message. I have no root account but I used sudo to issue the systemctl command. Unfortunately I have no way of capturing the output except by photographing the screen and with the reflection of this oled display it’s pretty bad.
You have a root account. You just need to set a password on it.
If you sign in with your normal account and then use “sudo”, the results are less useful because you are seeing the processes running in your virtual terminal “in the mix”. If you want to be able to spot what process is taking a long time to stop when you sign out from your account, you need to sign in with root directly and you will want to have the command queued up and ready to run quickly when you sign out from the GUI. So sign in with root on a VT. Type the command to show the user’s process tree, but don’t hit enter yet. Switch back to the GUI with Ctrl+Alt+F1, sign out, then quickly hit Ctrl+Alt+F3 again and press enter to see what process(es) is/are still stopping.
P.S. There is probably an easier way to get this info from the logs, but I don’t know the better way.
May 17 13:22:57 Potsdam systemd[7927]: Stopped plasma-powerdevil.service - Powerdevil.
May 17 13:22:57 Potsdam systemd[7927]: plasma-polkit-agent.service: Main process exited, code=exited, status=1/FAILURE
May 17 13:22:57 Potsdam systemd[7927]: plasma-polkit-agent.service: Failed with result ‘exit-code’.
May 17 13:22:57 Potsdam systemd[7927]: Stopped plasma-polkit-agent.service - KDE PolicyKit Authentication Agent.
May 17 13:22:57 Potsdam systemd[7927]: Stopped plasma-kwin_wayland.service - KDE Wayland Compositor.
May 17 13:22:57 Potsdam systemd[7927]: plasma-kwin_wayland.service: Consumed 8.994s CPU time over 35.212s wall clock time, 174.2M memory peak.
May 17 13:22:57 Potsdam systemd[7927]: app-flatpak-com.usebottles.bottles-2527741192.scope: Consumed 34.334s CPU time over 33.043s wall clock time, 519.4M memory peak.
May 17 13:22:58 Potsdam plasmalogin-helper[7921]: pam_unix(plasmalogin:session): session closed for user unraid
May 17 13:22:58 Potsdam plasmalogin-helper[7921]: pam_kwallet5(plasmalogin:session): pam_kwallet5: pam_sm_close_session
May 17 13:22:58 Potsdam plasmalogin-helper[7921]: pam_kwallet5(plasmalogin:setcred): pam_kwallet5: pam_sm_setcred
May 17 13:22:57 Potsdam systemd[7927]: plasma-kwin_wayland.service: Consumed 8.994s CPU time over 35.212s wall clock time, 174.2M memory peak.
May 17 13:22:57 Potsdam systemd[7927]: app-flatpak-com.usebottles.bottles-2527741192.scope: Consumed 34.334s CPU time over 33.043s wall clock time, 519.4M memory peak.
I would strongly have a look at Mullvad VPN gui failing to exit after its daemon stops (not uncommon that electron apps ignore sigterm and sit out the full 45s kill timeout..
Best to rule out or confirm after a bad shutdown with:
journalctl -b -1 -e | grep -iE ‘killing|SIGKILL|still running|timed out’
and look for a line like: Killing process NNNN (mullvad-gui) with signal SIGKILL` > names the offender
To try: fully quit Mullvad (not close-to-tray) before rebooting and see if it helps.
I did 4 restarts after quitting Roon first. Roon is a piece of Windows software sadly not available for Linux that I run using Bottles. The timeout behaviour is gone. I didn’t quit Bottles, I quit the piece of software using it. This seems to have solved the system waiting for whatever.
Or is it solved? I had a 39s timeout as well just now but that doesn’t appear consistently, in fact it just happened once.
Retype the command by hand using straight single quotes or (quote free):
journalctl -b -1 -e | grep -iE killing|SIGKILL|still\ running|timed\ out
or:
journalctl -b -1 -e | grep -i killing
That command only finds the kill messages if boot -1 is one that actually hung. Your last few reboots were clean (after quitting Roon), so -b -1 will look tidy with nothing to find.
To see the evidence from when it was hanging, count back to an older boot. List your boots first: journalctl --list-boots
Then check the earlier ones that ended in the timeout; try -b -5, -b -6, etc. (whichever predate your Roon fix): journalctl -b -5 -e | grep -i killing
Then look for a line naming “com.usebottles.bottles” being killed with SIGKILL after timing out.
Edit: this new one is different (39s, one time as it seems) and can be caused by many things diags the same if it freq. happens: journalctl -b -1 -e | grep -i killing
Well I see this for the last 15 reboots. The missing numbers did not return anything.
The behaviour is gone if I close Roon (Bottles) before restarting.
It also looks like logging out and running reboot in the shell avoids the timer.
journalctl -b -14 -e | grep -i killing
May 17 12:36:12 Potsdam systemd[19768]: app-flatpak-com.usebottles.bottles-1425303033.scope: Stopping timed out. Killing.
May 17 12:36:12 Potsdam systemd[19768]: app-flatpak-com.usebottles.bottles-1425303033.scope: Killing process 20955 (bwrap) with signal SIGKILL.
May 17 12:36:12 Potsdam systemd[19768]: app-flatpak-com.usebottles.bottles-1425303033.scope: Killing process 21834 (winedevice.exe) with signal SIGKILL
journalctl -b -13 -e | grep -i killing
May 17 12:42:49 Potsdam systemd[2003]: app-flatpak-com.usebottles.bottles-125957798.scope: Stopping timed out. Killing.
May 17 12:42:49 Potsdam systemd[2003]: app-flatpak-com.usebottles.bottles-125957798.scope: Killing process 3147 (bwrap) with signal SIGKILL.
May 17 12:42:49 Potsdam systemd[2003]: app-flatpak-com.usebottles.bottles-125957798.scope: Killing process 4813 (winedevice.exe) with signal SIGKILL.
journalctl -b -10 -e | grep -i killing
May 17 14:04:39 Potsdam systemd[13127]: app-mullvad\x2dvpn@autostart.service: Killing process 14037 (mullvad-gui) with signal SIGABRT.
May 17 14:04:44 Potsdam systemd[13127]: app-mullvad\x2dvpn@autostart.service: State ‘stop-watchdog’ timed out. Killing.
May 17 14:04:44 Potsdam systemd[13127]: app-mullvad\x2dvpn@autostart.service: Killing process 14037 (mullvad-gui) with signal SIGKILL.
journalctl -b -5 -e | grep -i killing
May 17 14:29:50 Potsdam systemd[2012]: plasma-plasmashell.service: Killing process 2582 (plasmashell) with signal SIGABRT.
OK it seems my system is waiting 45s for Bottles when Bottles is running and it tries to shut down. I guess that’s it. I can shut down Bottles before rebooting or I can wait it out?
Actually, there are 3 ‘offenders’.
Boots -14 and -13: Roon/Bottles com.usebottles.bottles scope timed out, SIGKILL on bwrap and winedevice.exe, seems the most frequent (close Roon as solution).
Boot -10: Mullvad mullvad-gui, via its own watchdog timeout. Occasional/independent and apparently its own failure mode, likely your one-off 39s hang.
Boot -5: plasmashell, KDE’s shell didn’t exit cleanly that time, rare/intermittent.
You may consider limiting the wait-time (can’t babysit Mullvad or plasmashell behaviorally ) under [Manager] in /etc/systemd/user.con: DefaultTimeoutStopSec=10s
I saw in the software app on gnome, that there are 3 versions of bottles you can install. RPM version and a system and user version from flatpak.
I could imagine that you use the system wide bottles which not lets you kill this apps, running on it.
If you use your computer alone, try the user version of the flatpak. It will run then in your user space and terminating apps will not fall into a time out, because of user rights. I can not prove it, however would be worth a test.
