[Solved] Slow launch of GTK3 apps with dbus-run-session

Sourav · 2020-10-26 19:51:19

I am user of gnome-screenshot and gnome-characters.
I do lunch gnome-characters with:

dbus-run-session /usr/bin/gnome-characters

I use gnome-characters with dbus-run-session to spawn as many windows as I like. Sometimes I need 2 windows of gnome-characters.

I recently upgraded my system. These packages were upgraded:

dhcpcd-9.3.1-1-x86_64.pkg.tar.zst
gcolor3-2.4.0-2-x86_64.pkg.tar.zst
gnome-keyring-1:3.36.0-1-x86_64.pkg.tar.zst
gst-plugins-bad-1.18.0+54+gbd3532008-1-x86_64.pkg.tar.zst
gst-plugins-bad-libs-1.18.0+54+gbd3532008-1-x86_64.pkg.tar.zst
linux-firmware-20201023.dae4b4c-1-any.pkg.tar.zst
pipewire-0.3.13-2-x86_64.pkg.tar.zst
poppler-data-0.4.10-1-any.pkg.tar.zst
python-pygments-2.7.2-1-any.pkg.tar.zst
xdg-desktop-portal-1.8.0-1-x86_64.pkg.tar.zst
xdg-desktop-portal-gtk-1.8.0-1-x86_64.pkg.tar.zst

I am using SSD, so before the upgrade, the apps used to lunch in no time at all.

But after the upgrade, dbus-run-session with a gtk app is taking > 10 seconds to load.
I am also getting way too many warnings.

Before upgrade:

$ dbus-run-session gnome-screenshot --interactive
dbus-daemon[819]: [session uid=1000 pid=819] Activating service name='org.gtk.vfs.Daemon' requested by ':1.0' (uid=1000 pid=820 comm="gnome-screenshot --interactive ")
dbus-daemon[819]: [session uid=1000 pid=819] Successfully activated service 'org.gtk.vfs.Daemon'
fusermount3: failed to access mountpoint /run/user/1000/gvfs: Permission denied

And the app launches immediately.

After the upgrade:

$ dbus-run-session gnome-screenshot --interactive
dbus-daemon[3508]: [session uid=1000 pid=3508] Activating service name='org.gtk.vfs.Daemon' requested by ':1.0' (uid=1000 pid=3509 comm="gnome-screenshot --interactive ")
dbus-daemon[3508]: [session uid=1000 pid=3508] Successfully activated service 'org.gtk.vfs.Daemon'
fusermount3: failed to access mountpoint /run/user/1000/gvfs: Permission denied
dbus-daemon[3508]: [session uid=1000 pid=3508] Activating service name='org.freedesktop.portal.Desktop' requested by ':1.0' (uid=1000 pid=3509 comm="gnome-screenshot --interactive ")
dbus-daemon[3508]: [session uid=1000 pid=3508] Activating service name='org.freedesktop.portal.Documents' requested by ':1.2' (uid=1000 pid=3522 comm="/usr/lib/xdg-desktop-portal ")
dbus-daemon[3508]: [session uid=1000 pid=3508] Activating service name='org.freedesktop.impl.portal.PermissionStore' requested by ':1.3' (uid=1000 pid=3527 comm="/usr/lib/xdg-document-portal ")
dbus-daemon[3508]: [session uid=1000 pid=3508] Successfully activated service 'org.freedesktop.impl.portal.PermissionStore'
dbus-daemon[3508]: [session uid=1000 pid=3508] Successfully activated service 'org.freedesktop.portal.Documents'
dbus-daemon[3508]: [session uid=1000 pid=3508] Activating service name='org.freedesktop.impl.portal.desktop.gtk' requested by ':1.2' (uid=1000 pid=3522 comm="/usr/lib/xdg-desktop-portal ")
dbus-daemon[3508]: [session uid=1000 pid=3508] Activating service name='ca.desrt.dconf' requested by ':1.5' (uid=1000 pid=3544 comm="/usr/lib/xdg-desktop-portal-gtk ")
dbus-daemon[3508]: [session uid=1000 pid=3508] Successfully activated service 'ca.desrt.dconf'
dbus-daemon[3508]: [session uid=1000 pid=3508] Successfully activated service 'org.freedesktop.impl.portal.desktop.gtk'
dbus-daemon[3508]: [session uid=1000 pid=3508] Activating service name='org.freedesktop.secrets' requested by ':1.2' (uid=1000 pid=3522 comm="/usr/lib/xdg-desktop-portal ")

It hangs there for 10 seconds or so, then the app launches.

What's wrong?

Last edited by Sourav (2020-10-27 06:49:13)

seth · 2020-10-26 21:19:02

Nothing is wrong.
The session (now?) kicks of a flatpack environment what apparently takes time.
Uninstalling flatpack and probably xdg-desktop-portal will probably accelerate things.

What's worse is "I use gnome-characters with dbus-run-session to spawn as many windows as I like."
That's insane. You're running a sub-session to get the process to allow a second instance to get a second window. That's insane.

gnome-characters doesn't seem to have a manpage, but if there's *really* no way to launch multiple instance or at least windows of what seems to be a character picker, file an upstream bug and ask them to add one.
There's no hard reason to limit this. If they reject for whatever reason, just stop to use the program.

Sourav · 2020-10-26 21:31:09

That made no sense.

1. I read somewhere dbus-run-session can run more than one instance of `gnome-screenshot --interactive` or gnome-characters, really. I have been doing that for 2 years. Yeah theoretically it might be a bad idea, but practically I never ever had a single problem with that.

2. "but if there's *really* no way to launch multiple instance or at least windows of what seems to be a character picker, file an upstream bug and ask them to add one."

That's what your solution is, app didn't work, you leave it. But to me, it's really useful to run dbus-run-session to launch 5 - 6 windows of an app with same window class. In GTK3, there's no way to spawn multiple windows otherwise.

3. The problem occurred after today's upgrade. There was no problem even a couple of hours ago, before the upgrade. Is there a bug with the xdg-desktop-portal-gtk-1.8.0?

Sourav · 2020-10-26 21:35:28

There's another way of launching more than one gnome-screenshot or gnome-characters, which is:

dbus-launch gnome-screenshot --interactive

But like the above, this also takes similar amount of time, at least not less that 10 seconds. using sudo reduces the time like before, but that's not an actual solution...

dbus-launch spawns app for sure, but after exiting, the dbus-launch stays in the memory, consuming 1 - 2 MB for each app spawned. So dbus-run-session is a better way where exiting the launched app will also close the dbus-run-session. I can easily run a loop runs 100 times and spawns 100 gnome-screenshot --interactive window with dbus-run-session, but with dbus-launch, the 100 copy of dbus-launch stay in memory.

Last edited by Sourav (2020-10-27 07:00:09)

Sourav · 2020-10-26 21:48:14

The above problem was on my laptop, which I just upgraded. I do have PC runs Arch with similar versions of packages.

While trying to upgrade my PC:

sudo pacman -Syyuu
:: Synchronising package databases...
 core                  129.7 KiB   124 KiB/s 00:01 [######################] 100%
 extra                1632.1 KiB  1075 KiB/s 00:02 [######################] 100%
 community               5.2 MiB  1576 KiB/s 00:03 [######################] 100%
:: Starting full system upgrade...
resolving dependencies...
:: There are 3 providers available for xdg-desktop-portal-impl:
:: Repository extra
   1) xdg-desktop-portal-gtk  2) xdg-desktop-portal-kde
:: Repository community
   3) xdg-desktop-portal-wlr

And there's no /usr/lib/xdg-desktop-portal on my desktop, but it came on my laptop after the upgrade. This makes dbus-launch or dbus-run-session slower (after upgrade) on my laptop, but my desktop runs butter smooth like before.

seth · 2020-10-26 21:50:21

No, my solution would be to get that app fixed, in doubt do it myself (cause gnome devs can be stubborn)

You read that "somewhere" because "someone" found a convoluted way to work around an apparently buggy client (gnome-*).
Now your line of defense is that "this might theoretically be bad, but practically worked for me™ but now it doesn't" - yeah, guess what…

I don't know whether there's a "bug" w/ xdg-desktop-portal-gtk but if I were you, I'd first figure whether it's the immediate cause by dumping it (and flatpack) and see whether the issue remains.
If it is the trigger, there might be a bug or not. The slowdown might be due to a required feature and I assume in that case they won't cut it because you want to abuse sub-sessions to work around a bogus client.

In GTK3, there's no way to spawn multiple windows otherwise.

That's nonsense. This has nothing to do w/ gtk3. The process will check the dbus on whether there's a running instance and refuse to start. That's why generating a complete new session-bus effectively works around it.
It also means that the second instance won't be able to dbus-communicate w/ the rest of the session for other purposes, which might not bother you w/ this particular client but might break other usecases, which is why this approach is a stupid idea to begin with. Don't focus on somehow making it work better™, focus on not having to rely on that.

Edit: well, that's the cause. Also don't run "pacman -Syyuu" unless you actually understand what it does and why you're doing it. You can easily break stuff this way.
It's just "pacman -Syu" for regular use.

Also stop bumping your thread, edit your posts unless somebody has replied.

Last edited by seth (2020-10-26 21:53:16)

loqs · 2020-10-26 21:57:56

Somewhat related https://gitlab.gnome.org/GNOME/gnome-ch … /issues/41

Sourav · 2020-10-26 22:01:33

So are you telling me to write a whole new gnome-characters app (or ibus-typing-booster as an alternative)? That's nothing related to the question.

Also, did you know after the upgrade, gcolor3 fails to pick colour?

Last edited by Sourav (2020-10-26 22:01:43)

Sourav · 2020-10-26 22:03:13

BTW, the problem is fixed by forcefully removing xdg-desktop-portal xdg-desktop-portal-gtk
The packages got installed as dependency for Gcolor3.

sudo pacman -Rndd xdg-desktop-portal xdg-desktop-portal-gtk

But for whatever reason gcolor3 wasn't working after upgrade. Even after removing the above app (dependency of gcolor3), gcolor3 launches fine, but can't pick colour as before. So I have to stick with gcolor2 now, which works perfectly fine.

Last edited by Sourav (2020-10-26 22:05:26)

loqs · 2020-10-26 22:06:57

seth wrote:

Also stop bumping your thread, edit your posts unless somebody has replied.

You are being asked to follow the Code of conduct. Which you just ignored again.

seth · 2020-10-26 22:14:38

No again: I'd simply remove the stupid conflict check.

loqs pointed to the bug report that caused the introduction of this behavior, the merge request was actually applied, but the bug not closed.
https://gitlab.gnome.org/GNOME/gnome-ch … equests/42
The compromising patch is https://gitlab.gnome.org/GNOME/gnome-ch … 0c7190ef52 - should not be hard to undo.

As for gnome-color3, you removed a hard dependency - of course it won't work afterwards.

Sourav · 2020-10-26 22:21:55

I have launched a bug report:

https://gitlab.gnome.org/World/gcolor3/-/issues/126

Even with the dependency the app doesn't work. With the xdg-desktop-portal specifically, the whole `dbus-run-session` or `dbus-launch` is slow for any GTK3 app, even tested with my own GTK3 app.

But anything that doesn't need GTK3, like gcolor2 for example, isn't affected.

As I learnt now that the question that I asked emerges from the xdg-desktop-portal, and gcolor3 actually.

Edit: Removing gcolor3 fixes the issue. Marking the thread as solved.

Last edited by Sourav (2020-10-27 06:48:52)

Arch Linux

#1 2020-10-26 19:51:19

[Solved] Slow launch of GTK3 apps with dbus-run-session

#2 2020-10-26 21:19:02

Re: [Solved] Slow launch of GTK3 apps with dbus-run-session

#3 2020-10-26 21:31:09

Re: [Solved] Slow launch of GTK3 apps with dbus-run-session

#4 2020-10-26 21:35:28

Re: [Solved] Slow launch of GTK3 apps with dbus-run-session

#5 2020-10-26 21:48:14

Re: [Solved] Slow launch of GTK3 apps with dbus-run-session

#6 2020-10-26 21:50:21

Re: [Solved] Slow launch of GTK3 apps with dbus-run-session

#7 2020-10-26 21:57:56

Re: [Solved] Slow launch of GTK3 apps with dbus-run-session

#8 2020-10-26 22:01:33

Re: [Solved] Slow launch of GTK3 apps with dbus-run-session

#9 2020-10-26 22:03:13

Re: [Solved] Slow launch of GTK3 apps with dbus-run-session

#10 2020-10-26 22:06:57

Re: [Solved] Slow launch of GTK3 apps with dbus-run-session

#11 2020-10-26 22:14:38

Re: [Solved] Slow launch of GTK3 apps with dbus-run-session

#12 2020-10-26 22:21:55

Re: [Solved] Slow launch of GTK3 apps with dbus-run-session

Board footer