Hi guys,
for about two weeks now I get the follwing looooooooooong reboot times. Can’t be reproduced after a fresh bott and reboot but I suppose after some work with a suspend/resume in between. I haven’t played with which circumstances produce the long reboot time.
Also it doesn’t matter if I user reboot from GUI or do a sudo reboot.
I have this gap in the output
Apr 06 17:35:49 t14 systemd[1545]: plasma-kded.service: Failed with result 'timeout'.
Apr 06 17:35:49 t14 systemd[1545]: plasma-kded.service: Killing process 46899 (zsh) with signal SIGKILL.
Apr 06 17:35:49 t14 systemd[1545]: plasma-kded.service: Killing process 9061 (zsh) with signal SIGKILL.
Apr 06 17:35:49 t14 systemd[1545]: plasma-kded.service: State 'final-sigterm' timed out. Killing.
Apr 06 17:34:29 t14 systemd[1]: upower.service: Consumed 5.265s CPU time.
Apr 06 17:34:29 t14 systemd[1]: Stopped Daemon for power management.
Apr 06 17:34:29 t14 systemd[1]: upower.service: Failed with result 'timeout'.
Apr 06 17:34:29 t14 systemd[1]: upower.service: Main process exited, code=killed, status=9/KILL
complete bootlog from submitting reboot is attached
I have no clue what may cause this. I only remember that I installed joplin as an appimage from repo and I use an USB stick to automatically decrypt my disc when docked @ home.
Any ideas where to investigate?
bootlog.txt
LOL this report is confusing because it has the newest entries first, it’s hard to read from bottom to up. The system might be having a problem closing one of the Plasma services. “plasma-kded.service” timed out, according to the report. There are a bunch of messages about “bluetoothd” also.
Just for me to understand it right.
I see reboot as 2 parts/processes:
- shutting down
- booting again
Is it taking long time to shut down or to boot again?
it’s the shutdown that takes long.
I reverted to the old process with no luks decrypting usb stick in my dock and a autologin in sddm. Let’s see if that’s the culprit.
although same scenario works well on a second - nearly identical - laptop…
I expected this honestly. I had it before. I do not know what causes it. I hope you will find the solution by enabling the “REISUB”. More details at my thread Restarting -> stop job for user running!
I do not know what really caused it, it happened randomly, but recently I am not having it frequently. I was (if I remember correctly) using Grub, but I do not know if it is related or not.
Please let me know how it goes.
If you need any help do not hesitate to ask.
I hope this helps.
I can’t say for sure that it is the exact same cause, but I had about one month ago the same behaviour on 3 computers, all running EOS with KDE and Wayland.
The solution for me was to replace sddm (the KDE display manager) by the git version : sddm-git from the AUR (in fact there is at the moment an even newer version in chaotic-aur, if you use it).
Just run : yay -S sddm-git
Next time you shutdown you’ll still have the long time waiting, but it should be gone after the next reboot.
See here the original post: Shutdown hangs at stop job for Simple Desktop Display Manager - #3 by BS86
All the best of luck.
1 Like
Yes I read about the sddm issue. But I’m on X11.For the moment disabling my USB-Key to decrypt partition and having the autologin in sddm seems to bring back the old behaviour. May be it’s just the plugged in USB-Key and sddm has nothing to do with it. Will wait a while and report back here 
1 Like
small update after 1 week of several reboots: since I removed the USB-decryption key from the docking station and set SDDM to autologin I didn’t have any problems.
Don’t know what exactly solved my issue, but I suppose it was the USB key that may be didn’t unmount or sth. like that.
Second laptop on another dock wit an USB decryption key does NOT have that problem.
The problematic stick is very old (128MB) and quite slow.
But I’m happy for now.
1 Like
So, the USB key is not the problem I guess.
Did you look at Restarting -> stop job for user running!
I hope it helps.