Is there a way to diagnose that kind of problem? Last time i did zypper dup it happened. How do i track something that happens during the shutdown process? Shutdown process takes like 20 secs rather than the usual like… 5.
While it’s shutting down, hit the Esc key to see console messages. You might see a message about some service taking longer to shut down.
Systemd sends a SIGTERM first to signal any active processes to terminate in an orderly way (cleaning up whatever they need to clean up, releasing system resources, closing files etc.), and after a timeout, if those processes are still active, it sends a SIGKILL. But that timeout is very long by default, and that can delay the overall shutdown a lot.
Finding out what services or in general processes take so long is the first step.
I found that the default timeouts (90 seconds) are insanely long, so I have this to reduce them to reasonable values:
% cat /etc/systemd/system.conf.d/50-huha-timeouts.conf
[Manager]
DefaultTimeoutStartSec=20s
DefaultTimeoutStopSec=10s
DefaultTimeoutAbortSec=10s
DefaultDeviceTimeoutSec=12s
YMMV, of course.
You can see the system defaults at /usr/lib/systemd in system.conf and user.conf. Add those that you want to override to a file in /etc/systemd/system.conf.d.
But reducing the timeouts is only the second line of defense; in most cases it’s best to find what processs takes so long, and why. Often it’s just forgotten user session at a virtual console or via ssh, or a busy mount that can’t be unmounted because some process still holds an open file handle to it.
4 Likes
I keep getting stopjob uuid 1000. It’s the thing that takes 30 secs or so. Any ideas? I tried googling but i keep getting ubuntu solutions.
Are you sure it is uuid and not uidor UID?
When UIDthen that is something running for or by user with UID 1000. Probably you as your normal user.
But isn’t there also a PID (Process IDentification) number mentioned in that message?
Ubuntu solutions should work as well for this deep system level; it’s systemd for both openSUSE and Ubuntu.
Check if you have an ssh session to or from that machine running. Try logging out from your desktop session and shut down from your login manager; if that makes a difference (which is likely), check if you are starting a process that your desktop doesn’t shut down when the desktop shuts down. Check the desktop’s autostart folder if there is anything new; maybe something that you explicitly added there.
And pretty certainly the message is about uid 1000 (the first user account created, typically yours), not uuid; UUIDs have a different format like f3471d8b-5fff-4d56-ab83-a1e5cc1e23da, i.e. long hex numbers, not nice round decimal numbers like 1000.
1 Like
Nohting in the desktop folder at least.
I have done more to try and fix this. journalctl should ideally get me an answer, but i don’t know where to look. I try and search for “stop job” but i don’t find anything there.
Help? It’s hard to find what it is having trouble with.
There were several questions and suggestions above. When you do not answer to them, why should people here answer you?
I did try. The autostart folder has nothing. I logged out and then shut down, same thing, still hangs on that one thing.
I could change the timeout to 5 secs, but that’d not solve the root issue.
After a lot of searching using journalctl over and over again for 2 hours i came upon this.
gvfs-daemon.service: Killing process 3364 (gvfsd-fuse) with signal SIGKILL.
May 21 15:16:05 localhost.localdomain systemd[3234]: gvfs-daemon.service: Killing process 6883 (fusermount3) with signal SIGKILL.
May 21 15:16:05 localhost.localdomain systemd[3234]: gvfs-daemon.service: Killing process 6886 (umount) with signal SIGKILL.
May 21 15:16:05 localhost.localdomain systemd[3234]: gvfs-daemon.service: Failed to kill control group /user.slice/user-1000.slice/user@1000.service/session.slice/gvfs-daem>
May 21 15:16:05 localhost.localdomain systemd[3234]: gvfs-daemon.service: Unit process 6886 (umount) remains running after unit stopped.
May 21 15:16:05 localhost.localdomain systemd[3234]: gvfs-daemon.service: Unit process 3364 (gvfsd-fuse) remains running after unit stopped.
Shutdown failed: GDBus.Error:org.freedesktop.login1.BlockedByInhibitorLock: Operation denied
May 18 21:04:56 localhost.localdomain systemd[2845]: gvfs-daemon.service: Failed to kill control group /user.slice/user-1000.slice/user@1000.service/session.slice/gvfs-daemon.service, ignoring: Operation not permitted
May 18 21:04:56 localhost.localdomain systemd[2845]: gvfs-daemon.service: Killing process 2960 (gvfsd-fuse) with signal SIGKILL.
May 18 21:04:56 localhost.localdomain systemd[2845]: gvfs-daemon.service: Killing process 8204 (fusermount3) with signal SIGKILL.
May 18 21:04:56 localhost.localdomain systemd[2845]: gvfs-daemon.service: Killing process 8207 (umount) with signal SIGKILL.
May 18 21:04:56 localhost.localdomain systemd[2845]: gvfs-daemon.service: Failed to kill control group /user.slice/user-1000.slice/user@1000.service/session.slice/gvfs-daemon.service, ignoring: Operation not permitted
May 18 21:04:56 localhost.localdomain systemd[2845]: gvfs-daemon.service: Unit process 8207 (umount) remains running after unit stopped.
What do i make of this? It all sounds so complicated.
Edit by Sauerland:
Code-Tags.
Please use Code-tags, see:
Code-Tags
1 Like
Ty! That makes it more navigable.
Apparently there is still a user filesystem that refuses to be unmounted at shutdown: an external disk or an SD card or??
Try to disconnect every memory device before shutdown and see what happens.
External disk no, but there’s a HDD on the side of the SSD if that counts. I’m not sure if i can remove it since it probably would break links in the computer regarding it knowing where HDD stuff is for programs.
So possibly some application is still using that filesystem at shutdown?
Try to close all apps, logout every user before shutting down and see if that makes any difference?
Tried! I shut down as usual, then when booting up was finished i put up a window of chromium and then closed it, then logged out and then proceeded to shut down. I still got the same wait again.
I wish it was easier to debug this, because it’s incredibly hard to find what’s wrong. Like big red text saying ERROR SHUTDOWN FAILED TO KILL PROCESS “EXAMPLE-DAEMON”. I’ve been at it for hours at this point.
Anything suspicious from systemctl --user -v restart gvfs-daemon (run from the current user)?
May 24 16:19:48 localhost.localdomain systemd[2765]: Stopping Virtual filesystem service...
May 24 16:19:48 localhost.localdomain systemd[2765]: Stopped Virtual filesystem service.
May 24 16:19:48 localhost.localdomain systemd[2765]: Starting Virtual filesystem service...
May 24 16:19:49 localhost.localdomain systemd[2765]: Started Virtual filesystem service.
Here’s the output. To my eyes it doesn’t seem strange. Shutdown time was the same as before with uuid 1000 going all wait wait wait. At some point it’d be easier to reinstall.
I guess you mean “UID 1000”; so to rule out some odd config in that user, does logging in another user, or better still a fresh user just created, change something?
Other users do not seem to change it, same issue. I made a backup of my HDD and then unmounted it, it seems to have solved the problem, it now shuts down instantly. However i need that HDD on always, is there a way to unmount it automatically at shutdown?