Due to a ‘Stop job’ still running and delaying the system shutdown yesterday, I noticed somehow flatpak to be involved.
… xdg-document-portal.service: State 'stop-sigterm' timed out. Killing.
… xdg-document-portal.service: Killing process 2295 (xdg-document-po) with signal SIGKILL.
… xdg-document-portal.service: Killing process 2301 (fusermount3) with signal SIGKILL.
… xdg-document-portal.service: Killing process 2300 (fuse mainloop) with signal SIGKILL.
… xdg-document-portal.service: Main process exited, code=killed, status=9/KILL
… xdg-document-portal.service: Failed with result 'timeout'.
… Stopped flatpak document portal service.
I checked flatpak list but it doesn’t return a result which to me means I don’t have anything installed depending on flatpak, right?
Just to be on the safe side, is it really okay to remove flatpak or is anything from the OS depending on it which I don’t see/comprehend?
The Manjaro wiki doesn’t warn about anything which leads me to believe I can get rid of flatpak for good.
Usually one should simply wait for a stop job to complete; sometimes they might last a few minutes, depending on just what needs to complete. Stopping it prematurely usually serves no purpose; it will then likely occur again at the next reboot or shutdown.
Nothing in the Manjaro system depends on Flatpak.
Installed Flatpak based applications, of course, rely on some supporting infrastructure - removing that will render those apps unmanageable. If you don’t use Flatpak at all, it’s safe to completely remove the support as described on the Wiki page you linked.
xdg-document-portal.service delaying shutdown seems to be a known issue:
I don’t think flatpak has anything to do with the issue, as the flatpak document portal service was successfully stopped. Something before that is causing the xdg-document-portal.service to wait until a stop job completes, at which time it force kills the process it was waiting upon. You might need to look at entries a bit earlier in your logs to see what leads up to this line:
One possible cause:
Do you happen to have pika-backup installed on your system? If you do, then it may be the cause of the problem. This temporary fix from the most recent post in that reported issue may resolve the situation for you:
A band-aid fix is to put the following in a new file /usr/lib/systemd/system-shutdown/kill-pika.shutdown (should be owned by root and have execute permissions):
I was under the impression it’s because of flatpak because of it stopping immediately after that in the journal but you’re right. I just searched for xdg-document-portal.service the next day (after the Stop job delaying the shutdown) and the first link took me to the ArchWiki where it’s put into flatpak context as well.
I added that all up and came to the (false?) conclusion, it must be a flatpak issue. After checking flatpak list and realizing that I don’t have any more of these apps installed, I thought why not getting rid of it to avoid further stop jobs.
No. I don’t have it installed. I’m using borgbackup (Vorta) and TimeShift (rsync).
Hmm, there’s nothing obvious to me but the first few lines before that read:
… systemd[1629]: Stopped Virtual filesystem service.
… systemd[1629]: Stopped Application launched by gnome-session-binary.
… systemd[1629]: Removed slice Slice /app/dbus-:1.2-org.gnome.Identity.
… systemd[1629]: Removed slice Slice /app/dbus-:1.2-org.gnome.OnlineAccounts.
… systemd[1629]: Removed slice Slice /app/dbus-:1.2-org.gnome.Shell.CalendarServer.
… systemd[1629]: Stopping Multimedia Service Session Manager...
… wireplumber[2186]: pw.core: 0x55de1c3a8e60: leaked proxy 0x55de1c64c9d0 id:3
… wireplumber[2186]: pw.core: 0x55de1c3a8e60: leaked proxy 0x55de1c3bdb90 id:4
… systemd[1629]: Stopped Multimedia Service Session Manager.
… systemd[1629]: wireplumber.service: Consumed 5.553s CPU time, 12M memory peak.
… systemd[1629]: Stopping PipeWire Multimedia Service...
… systemd[1629]: Stopped PipeWire Multimedia Service.
… systemd[1629]: pipewire.service: Consumed 35.096s CPU time, 18.7M memory peak.
… systemd[1629]: Stopped Tracker file system data miner.
… systemd[1629]: localsearch-3.service: Consumed 603ms CPU time, 65.2M memory peak.
… systemd[1629]: Removed slice User Background Tasks Slice.
… systemd[1629]: background.slice: Consumed 603ms CPU time, 65.2M memory peak.
--> Stop job starts here
… systemd[1629]: xdg-document-portal.service: State 'stop-sigterm' timed out. Killing.
… systemd[1629]: xdg-document-portal.service: Killing process 2295 (xdg-document-po) with signal SIGKILL.
… systemd[1629]: xdg-document-portal.service: Killing process 2301 (fusermount3) with signal SIGKILL.
… systemd[1629]: xdg-document-portal.service: Killing process 2300 (fuse mainloop) with signal SIGKILL.
… systemd[1629]: xdg-document-portal.service: Main process exited, code=killed, status=9/KILL
… systemd[1629]: xdg-document-portal.service: Failed with result 'timeout'.
There are a couple of warnings further up in the journal (but still connected to the shutdown process):
journal.log
… gnome-shell[1732]: Connection to xwayland lost
… gnome-shell[1732]: (../mutter/src/core/meta-context.c:596):meta_context_terminate: runtime check failed: (priv->state == META_CONTEXT_STATE_RUNNING)
… gnome-shell[1732]: g_main_loop_is_running: assertion 'loop != NULL' failed
… gnome-shell[1732]: (../mutter/src/core/meta-context.c:597):meta_context_terminate: runtime check failed: (g_main_loop_is_running (priv->main_loop))
… gnome-shell[1732]: g_main_loop_quit: assertion 'loop != NULL' failed
… gnome-shell[1732]: Owner of volume monitor org.gtk.vfs.AfcVolumeMonitor disconnected from the bus; removing drives/volumes/mounts
… gnome-shell[1732]: Owner of volume monitor org.gtk.vfs.GoaVolumeMonitor disconnected from the bus; removing drives/volumes/mounts
… gnome-shell[1732]: Owner of volume monitor org.gtk.vfs.GPhoto2VolumeMonitor disconnected from the bus; removing drives/volumes/mounts
… systemd[1]: gdm.service: Deactivated successfully.
… gnome-shell[1732]: Owner of volume monitor org.gtk.vfs.MTPVolumeMonitor disconnected from the bus; removing drives/volumes/mounts
… systemd[1]: Stopped GNOME Display Manager.
… gnome-shell[1732]: Object Gjs_status_backgroundApps_BackgroundAppsToggle (0x55673547a5f0), has been already disposed — impossible to set any property on it. This might be caused by the object having been destroyed from C code using something such as destroy(), dispose(), or remove() vfuncs.
== Stack trace for context 0x55673127d9a0 ==
#0 556731373ed8 i resource:///org/gnome/shell/ui/status/backgroundApps.js:197 (2c81a7273dd0 @ 163)
#1 556731373e28 i resource:///org/gnome/shell/ui/status/backgroundApps.js:201 (2c81a7273e20 @ 34)
#2 556731373da8 i resource:///org/gnome/shell/ui/status/backgroundApps.js:164 (2c81a7273c90 @ 12)
#3 556731373d08 i resource:///org/gnome/shell/ui/main.js:272 (39a0005d9380 @ 119)
… gnome-shell[1732]: Object St.BoxLayout (0x556735499620), has been already disposed — impossible to access it. This might be caused by the object having been destroyed from C code using something such as destroy(), dispose(), or remove() vfuncs.
== Stack trace for context 0x55673127d9a0 ==
#0 7fffd35d5de0 b resource:///org/gnome/shell/ui/popupMenu.js:966 (13416f1243d0 @ 22)
#1 7fffd35d6390 b resource:///org/gnome/shell/ui/popupMenu.js:984 (13416f124560 @ 23)
#2 556731373e28 i resource:///org/gnome/shell/ui/status/backgroundApps.js:208 (2c81a7273e20 @ 107)
#3 556731373da8 i resource:///org/gnome/shell/ui/status/backgroundApps.js:164 (2c81a7273c90 @ 12)
#4 556731373d08 i resource:///org/gnome/shell/ui/main.js:272 (39a0005d9380 @ 119)
… gnome-shell[1732]: Object Gjs_ui_popupMenu_PopupMenuItem (0x5567354959a0), has been already disposed — impossible to set any property on it. This might be caused by the object having been destroyed from C code using something such as destroy(), dispose(), or remove() vfuncs.
== Stack trace for context 0x55673127d9a0 ==
#0 556731373e28 i resource:///org/gnome/shell/ui/status/backgroundApps.js:244 (2c81a7273e20 @ 340)
#1 556731373da8 i resource:///org/gnome/shell/ui/status/backgroundApps.js:164 (2c81a7273c90 @ 12)
#2 556731373d08 i resource:///org/gnome/shell/ui/main.js:272 (39a0005d9380 @ 119)
… gnome-shell[1732]: Owner of volume monitor org.gtk.vfs.UDisks2VolumeMonitor disconnected from the bus; removing drives/volumes/mounts
… gnome-shell[1732]: Using public X11 display :0, (using :1 for managed services)
… gnome-shell[1732]: Object Gjs_status_system_PowerToggle (0x556734a06f90), has been already disposed — impossible to set any property on it. This might be caused by the object having been destroyed from C code using something such as destroy(), dispose(), or remove() vfuncs.
== Stack trace for context 0x55673127d9a0 ==
#0 556731373e28 i resource:///org/gnome/shell/ui/status/system.js:72 (2c81a7267970 @ 50)
#1 556731373da8 i resource:///org/gnome/shell/ui/status/system.js:46 (2c81a7267830 @ 12)
#2 556731373d08 i resource:///org/gnome/shell/ui/main.js:272 (39a0005d9380 @ 119)
… gnome-shell[1732]: Object Gjs_status_system_PowerToggle (0x556734a06f90), has been already disposed — impossible to get any property from it. This might be caused by the object having been destroyed from C code using something such as destroy(), dispose(), or remove() vfuncs.
== Stack trace for context 0x55673127d9a0 ==
#0 556731373e28 i resource:///org/gnome/shell/ui/status/system.js:73 (2c81a7267970 @ 60)
#1 556731373da8 i resource:///org/gnome/shell/ui/status/system.js:46 (2c81a7267830 @ 12)
#2 556731373d08 i resource:///org/gnome/shell/ui/main.js:272 (39a0005d9380 @ 119)
… gnome-shell[1732]: Object Gjs_status_powerProfiles_PowerProfilesToggle (0x556735427670), has been already disposed — impossible to set any property on it. This might be caused by the object having been destroyed from C code using something such as destroy(), dispose(), or remove() vfuncs.
== Stack trace for context 0x55673127d9a0 ==
#0 556731373e40 i resource:///org/gnome/shell/ui/status/powerProfiles.js:100 (2c81a725f5b0 @ 40)
#1 556731373da8 i resource:///org/gnome/shell/ui/status/powerProfiles.js:58 (2c81a725f470 @ 79)
#2 556731373d08 i resource:///org/gnome/shell/ui/main.js:272 (39a0005d9380 @ 119)
… gnome-shell[1732]: Object Gjs_status_powerProfiles_PowerProfilesToggle (0x556735427670), has been already disposed — impossible to get any property from it. This might be caused by the object having been destroyed from C code using something such as destroy(), dispose(), or remove() vfuncs.
== Stack trace for context 0x55673127d9a0 ==
#0 556731373e40 i resource:///org/gnome/shell/ui/status/powerProfiles.js:102 (2c81a725f5b0 @ 50)
#1 556731373da8 i resource:///org/gnome/shell/ui/status/powerProfiles.js:58 (2c81a725f470 @ 79)
#2 556731373d08 i resource:///org/gnome/shell/ui/main.js:272 (39a0005d9380 @ 119)
… gnome-shell[1732]: Error checking authorization for action id org.freedesktop.NetworkManager.network-control: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name is not activatable
… gnome-shell[1732]: Error checking authorization for action id org.freedesktop.bolt.enroll: GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name is not activatable
… gnome-shell[1732]: Launching Adw-DING process
…
… systemd[1629]: dbus-:1.2-org.gnome.Calendar@0.service: Main process exited, code=exited, status=1/FAILURE
… systemd[1629]: dbus-:1.2-org.gnome.Calendar@0.service: Failed with result 'exit-code'.
… systemd[1629]: dbus-:1.2-org.gnome.Shell.Extensions.GSConnect@0.service: Main process exited, code=exited, status=1/FAILURE
… systemd[1629]: dbus-:1.2-org.gnome.Shell.Extensions.GSConnect@0.service: Failed with result 'exit-code'.
… dbus-broker-launch[791]: Activation request for 'org.freedesktop.ColorManager' failed.
…
Note:If you encounter errors while attempting to mount a backup (e.g. borg mount not available: no FUSE support or fuse: failed to exec fusermount3), it’s likely due to missing FUSE support on your system.
You obviously do have fuse support on your system, however the mentions of fuse in your log might make this paragraph at the end of the page relevant:
When you are finished restoring your files, close out all of your active windows, and hit the Unmount button.
Are you properly unmounting Vorta/Borg after using it? If not, you could be trying to shutdown your system with the backup drive still mounted, and that could be causing the delay with shutting down.
As an example, I have a 14TB external HDD permanently plugged into my mini-PC (using Plasma’s automount feature, so it mounts as /run/media/scotty/14TB-Elements). If that drive has powered down to standby/low energy mode before I shutdown, systemd has to spin it back up and unmount it properly before finishing the system shutdown. Spinning the drive back up before unmounting it usually adds around 20 seconds to the shutdown process, as you can see below for a shutdown I did an hour ago:
journalctl -b -1 --since "Aug 24 10:50:45" --until "Aug 24 10:51:05"
Aug 24 10:50:46 scott-ser kernel: EXT4-fs (sdb1): unmounting filesystem c39c1ced-caee-40e6-95f4-44d42eb5c574.
Aug 24 10:51:04 scott-ser systemd[1]: run-media-scotty-14TB\x2dElements.mount: Deactivated successfully.
Aug 24 10:51:04 scott-ser systemd[1]: Unmounted /run/media/scotty/14TB-Elements.
Aug 24 10:51:04 scott-ser systemd[1]: run-media-scotty-14TB\x2dElements.mount: Consumed 3.601s CPU time, 1.7M memory pe>
Aug 24 10:51:04 scott-ser systemd[1]: Stopped target Preparation for Local File Systems.
So, making sure any backup/external drives are properly unmounted, especially if they are no longer accessible (such as being on a remote network), is important if you want a fast shutdown.
Wow, 14 TB. I can’t seem to fill up my old 2TB drive.
Backup as root cause is a good idea but I’m not auto-starting Vorta and Timeshift but run them manually when needed like before an update. They were not running that day.
Those ‘stop jobs’ slowing down shutdown aren’t happening regularly which is why I’m always puzzled when they happen. That last one before the current occurrence happend probably months ago.
I tried searching the journal for the listed process ids (2295, 2301, 2300) but no further lines could be found. Are those maybe listed in some kind of ‘root’ journal because they’re not running in user context?
One of the problems with systemd is that, while it is very good at analysing boot times (using systemd-analyze), it doesn’t analyse shutdown times. It also doesn’t log the actual text of stop-jobs, which are the only way of seeing what is causing a shutdown hold-up.
Maybe you could change your boot parameters to display the boot/shutdown processes instead of the Plymouth splash screen as your system boots up and shuts down? It is quite easy to do (I’ve had my system set up this way for nearly 2 years):
For changes that persist across boots, open /etc/default/grub in a text editor. Or, to just make a temporary change for a single session, hit the e key when the GRUB menu appears during boot
At the line GRUB_CMDLINE_LINUX_DEFAULT= remove quiet and splash
At the line GRUB_CMDLINE_LINUX= set the following: plymouth.enable=0 disablehooks=plymouth
Save the changes
If you chose the option of editing the /etc/default/grub file, you should then apply the changes by running:
sudo grub-mkconfig -o /boot/grub/grub.cfg
Note: I believe that sudo update-grub will also do the same job as the above command.
Reboot, and you should then see the boot processes on-screen as your system starts up. You will also see the processes as it shuts down, including any stop-jobs and what they are waiting for. So, each time you shut down you can watch the screen and see if any delays occur & what causes them.
Note: you can also disable and remove Plymouth from your system completely if you want (as I have done). Instructions are here:
Seems like we’re thinking alike because I already did that back in May of last year when I had a mkinitcpio.pacnew file to merge and ran into some problems. In the course of fixing a ‘kms’ hook issue, I was also advised to get rid of Plymouth to get a glimpse on the startup and shutdown process/messages (which I prefer anyway).
That’s why I noticed the ‘Stop job’ blocking the shutdown in the first place.
I think that’s the crux of the issue. Upon revisiting our discussion, I was thinking to myself, what am I really looking an answer for. Turns out it’s not how to delete flatpak but understanding what caused this ‘stop job’/killing of xdg-document-portal.service.
That’s one reason why we usually ask members to include the output of inxi -zv8 when they post a support request. I would have immediately noticed that quiet & splash were not in your boot parameters, as can be seen in this extract from my own inxi -zv8:
xdg-document-portal.service is part of the xdg-desktop-portal package, which on Gnome (your user profile says Gnome is your DE) cannot be removed as xdg-desktop-portal-gnome depends on it.
My (Plasma) system info says that /usr/lib/xdg-document-portal has been running since boot, so it looks like it may be difficult to see what individual processes are calling upon it. The service is run as a user, not root, so you can check the status with:
systemctl --user status xdg-document-portal
Running that command on my system doesn’t reveal much though:
Output of scotty65's systemctl --user status xdg-document-portal
systemctl --user status xdg-document-portal
● xdg-document-portal.service - flatpak document portal service
Loaded: loaded (/usr/lib/systemd/user/xdg-document-portal.service; static)
Active: active (running) since Mon 2025-08-25 09:01:15 AEST; 22h ago
Invocation: d993e6a8e033452da835a21fd6ebb5f5
Main PID: 1003 (xdg-document-po)
Tasks: 8 (limit: 34689)
Memory: 2.1M (peak: 3.4M)
CPU: 1.147s
CGroup: /user.slice/user-1000.slice/user@1000.service/session.slice/xdg-document-portal.service
├─1003 /usr/lib/xdg-document-portal
└─1009 fusermount3 -o rw,nosuid,nodev,fsname=portal,auto_unmount,subtype=portal -- /run/user/1000/doc
Aug 25 09:01:15 scott-ser systemd[779]: Starting flatpak document portal service...
Aug 25 09:01:15 scott-ser systemd[779]: Started flatpak document portal service.
So I don’t know if that will be of much help to you. Apart from that, I’m really stumped as to the cause. You may just have to continue keeping an eye on every shutdown until it happens again, and make a pen & paper note of any line that says it is waiting for a stop-job or process to finish.
Also, when it comes to gtk applications, anything from gtk3 upwards uses the gtk portal anyway, because the GNOME/gtk developers still adhere to a belief system in which they’re the only people in the universe who create GUI software.
● xdg-document-portal.service - flatpak document portal service
Loaded: loaded (/usr/lib/systemd/user/xdg-document-portal.service; static)
Active: active (running) since Tue 2025-08-26 12:29:17 CEST; 3h 15min ago
Invocation: 304cbe6896c24e2ab5c39e19e77ef6e4
Main PID: 2293 (xdg-document-po)
Tasks: 8 (limit: 38295)
Memory: 1.3M (peak: 2.3M)
CPU: 42ms
CGroup: /user.slice/user-1000.slice/user@1000.service/session.slice/xdg-document-portal.service
├─2293 /usr/lib/xdg-document-portal
└─2299 fusermount3 -o rw,nosuid,nodev,fsname=portal,auto_unmount,subtype=portal -- /run/user/1000/doc
Aug 26 12:29:17 system12 systemd[1629]: Starting flatpak document portal service...
Aug 26 12:29:17 system12 systemd[1629]: Started flatpak document portal service.
In conclusion I have decided to remove flatpak completely and will also probably try out masking the xdg-document-portal service to see if I can live without it. This would mean a cleaner system after all.
I’ve rebooted and everything is working fine. journalctl --no-pager --boot=0 | grep "flatpak" confirms that xdg-document-portal isn’t automatically launched anymore.
Wow, 14 TB. I can’t seem to fill up my old 2TB drive.
