Very slow shutdown/reboot on Fedora 34

So, when i try to reboot or shutdown it takes about 2 minutes. When i press ESC while shutdown screen it says a stop job is running for user manager for UID 1000. I did some researh and found a fix. All of the topics related to this problem offered adding Slice=-.slice to end of gnome-session-restart-dbus.service. But there is already Slice=-.slice at the end. I was using beta and now i’m on stable and my system is up to date. What should i do? I am a total noob at Linux btw.


I notice about this issue in Beta. But it is fixed for me well before RC1.2 build (which is the GOLD version) .

Would you please do a full update and see if the same issue still there?

1 Like

How can i do a full update?

Please run sudo dnf update .

I’ve already done that but nothing changed. I also tried distro-sync but that didn’t help either.


This is a little tricky, but it might work. Try the following steps in order. You might have to be quick to spot the process that is taking too long to stop.

  1. Press Ctrl+Alt+F3 to switch to the third virtual terminal (use a higher number if necessary).
  2. Log in on the virtual terminal with your normal account
  3. Enter the following command to prevent this terminal from being killed on shutdown/reboot.
    $ trap "" HUP QUIT TERM KILL
  4. Press Ctrl+Alt+Del to initiate a reboot
  5. Press Alt+F3 to switch back to the third virtual terminal which should still be running.
  6. Run the following command to monitor the processes in your user session as they are terminated and see if you can figure out which one(s) are taking too long to stop.
    $ top -u $USER

Once all the processes have terminated, you should be able to press Q to quit the top program and enter exit to end the terminal session and allow the system to reboot.

P.S. Leave off the -u $USER part to monitor all system processes instead of just your own. Based on the error message that you originally provided, however, it looks like the problem is with something running under your user session.


Just tested with two system in virt-manager:

Fresh install of Fedora Linux 34 - not hit by the problem.

Fresh install of Fedora Linux 33 then upgrade to Fedora Linux 34 via gnome-software - it got hit by the reboot delay.

Immediate by seeing the message, I use send key of virt-manager, trying switch to ctrl+alt+f1 to f6, I only got a blanking β€˜-’, but no login prompts.

I did as you said and this is what i got. I’ve waited for some time and nothing happened and i quit.

I got a blanking β€œ-” too after i quit top.
Should i do a fresh install? I don’t really want to do but if it will fix it i can do it.

I have one notebook direct installs to Fedora Linux 34 RC1.2 and one VM direct installs to Fedora 34 GOLD. Both do not have this delay issue.

For my upgraded VM, the delay for me is 50 seconds.

May be you can try a fresh install in a VM first. There is a similar bug reported, but not much activities so far:

I’m downloading it right now but how can i know if I’m downloading RC1.2 or GOLD one?

You might check the output of journalctl -b -e (instead of top) to see if it provides any clues. The service(s) that are taking the longest to stop will probably be listed towards the bottom.

When you download from, it is the GOLD version.

Here. Hope it helps.

Ok thanks. I’ve downloaded from Gonna install it in VM now.

I’ve fresh installed in VM and there is no issue whatsoever. @sampsonf @glb What do you think? Should i do a fresh install? I don’t have lots of things in Fedora so it won’t be that hard.

It looks like gnome-shell-calendar-server is stopping late. It looks like it might be a known bug: 1930595 – [abrt] gnome-shell: __poll(): gnome-shell-calendar-server killed by SIGABRT

It should stop instantly along with everything else. For comparison, here is a recording of my PC shutting down: shutdown.svg

I found it necessary to use reboot && top in order to capture all the initial processes.

Thanks Sampson. Following the links a bit from there, the following troubleshooting tip can be found:

From BZ1847437 - Comment 5:

You can run
# systemd-cgls -u user-1000.slice
to see what processes are still alive in the user slice.

Someone experiencing this problem might want to try the above in their virtual terminal to see if it shows anything interesting.


It’s up to you. Since others also report the problem, they might appreciate if you can help to narrow down the problem. If you don’t feel like messing with it though, that is totally understandable.

I’d love to help the community. But i don’t really understand how to run reboot && top. When i run this from terminal it just reboots. When i go to other virtual terminal repeat the steps abovementioned, there is just blinking β€œ-”. I didn’t really understand what changed since i last tried it.

Also, when i run this command it gives me this:

Unit user-1000.slice (/user.slice/user-1000.slice):
β”‚ β”œβ”€session.slice 
β”‚ β”‚ β”œβ”€gvfs-goa-volume-monitor.service 
β”‚ β”‚ β”‚ └─2161 /usr/libexec/gvfs-goa-volume-monitor
β”‚ β”‚ β”œβ”€org.gnome.SettingsDaemon.MediaKeys.service 
β”‚ β”‚ β”‚ └─2222 /usr/libexec/gsd-media-keys
β”‚ β”‚ β”œβ”€org.gnome.SettingsDaemon.Smartcard.service 
β”‚ β”‚ β”‚ └─2236 /usr/libexec/gsd-smartcard
β”‚ β”‚ β”œβ”€dbus-broker.service 
β”‚ β”‚ β”‚ β”œβ”€1759 /usr/bin/dbus-broker-launch --scope user
β”‚ β”‚ β”‚ └─1762 dbus-broker --log 4 --controller 10 --machine-id 2b2b98c6fd0e49f8b>
β”‚ β”‚ β”œβ”€org.gnome.SettingsDaemon.Datetime.service 
β”‚ β”‚ β”‚ └─2211 /usr/libexec/gsd-datetime
β”‚ β”‚ β”œβ”€org.gnome.SettingsDaemon.Housekeeping.service 
β”‚ β”‚ β”‚ └─2214 /usr/libexec/gsd-housekeeping
β”‚ β”‚ β”œβ”€pipewire-pulse.service 
β”‚ β”‚ β”‚ └─2080 /usr/bin/pipewire-pulse
β”‚ β”‚ β”œβ”€org.gnome.SettingsDaemon.Keyboard.service 
β”‚ β”‚ β”‚ └─2218 /usr/libexec/gsd-keyboard
β”‚ β”‚ β”œβ”€org.gnome.SettingsDaemon.A11ySettings.service 
β”‚ β”‚ β”‚ └─2207 /usr/libexec/gsd-a11y-settings
β”‚ β”‚ β”œβ”€org.gnome.SettingsDaemon.Wacom.service 
lines 1-23

I can reproduce the problem in a VM upgraded from F33.
The issue persists even when rebooting right from GDM:

That’s OK. This is a particularly tricky problem to troubleshoot, so if just reinstalling works for you, that is a perfectly acceptable solution. If someone else wants to put in more effort, then they can pick up where you left off. Thanks for reporting the problem. :slightly_smiling_face: