Slow startup due to deadlock if o.fd.FileManager1 is implemented by GtkApplication #636
Comments
|
Do you happen to use |
|
Thank you, I removed |
smcv
changed the title
This issue was also reported in Debian, and from debug information provided by the bug reporter, this is the key factor. The problem is that xdg-desktop-portal calls into org.freedesktop.FileManager1 on startup (to find out whether it can be used to implement the OpenURI interface), and GTK's GtkApplication class (as used in e.g. Thunar) calls into the Inhibit portal on startup (to use it as a desktop-neutral way to offer an interface to inhinit screensaver/suspend/shutdown). This would be fine if they both used asynchronous D-Bus calls and continued to start up without waiting for a result, but they don't: they both use synchronous (blocking) D-Bus calls. This means neither one will successfully start up until it gets a reply from the other, causing a deadlock. The dbus-daemon waits for an arbitrary length of time for the two services to start up, then resolves the deadlock by deciding that service-activation is taking too long and sending an error reply. This will only happen in non-GNOME environments. If gnome-session is running, GTK bypasses the Inhibit portal abstraction and uses gnome-session's D-Bus interfaces directly, so this will not occur.
It's a bug in xdg-desktop-portal (and/or GTK, but I think it's going to be a lot easier to fix here than in GTK). Removing the -gtk backend probably only works around this by coincidence, because the -gtk backend provides the AppChooser interface (which is required for OpenURI) and the -wlr backend does not. xdg-desktop-portal will not have full functionality without an implementation of the AppChooser interface. |
After wasting some time trying to reproduce this in XFCE, make that "non-GNOME && non-XFCE environments"... (GTK has specific support for XFCE's session manager, too.) |
Making a synchronous call into a GTK implementation of o.fd.FileManager1 can cause a deadlock, because GtkApplication makes a synchronous call into the Inhibit portal when started in a non-GNOME, non-XFCE environment. In this situation, each service does not take its bus name (and hence complete service-activation) until it gets a reply from the other, which obviously can't work. We don't actually need a GDBusProxy here: we don't need to subscribe to any signals, watch any properties or hold any state, so it's just as straightforward to use g_dbus_connection_call_sync() on a just-in-time basis. Fixes: 69961f3 "openuri: Use FileManager1 in OpenDirectory" Resolves: flatpak#636 Signed-off-by: Simon McVittie <[email protected]>
Making a synchronous call into a GTK implementation of o.fd.FileManager1 can cause a deadlock, because GtkApplication makes a synchronous call into the Inhibit portal when started in a non-GNOME, non-XFCE environment. In this situation, each service does not take its bus name (and hence complete service-activation) until it gets a reply from the other, which obviously can't work. We don't actually need a GDBusProxy here: we don't need to subscribe to any signals, watch any properties or hold any state, so it's just as straightforward to use g_dbus_connection_call_sync() on a just-in-time basis. The indentation is deliberately a bit odd here, to avoid a large diffstat from re-indentation; it will be fixed in a subsequent commit. Fixes: 69961f3 "openuri: Use FileManager1 in OpenDirectory" Resolves: flatpak#636 Signed-off-by: Simon McVittie <[email protected]>
Making a synchronous call into a GTK implementation of o.fd.FileManager1 can cause a deadlock, because GtkApplication makes a synchronous call into the Inhibit portal when started in a non-GNOME, non-XFCE environment. In this situation, each service does not take its bus name (and hence complete service-activation) until it gets a reply from the other, which obviously can't work. We don't actually need a GDBusProxy here: we don't need to subscribe to any signals, watch any properties or hold any state, so it's just as straightforward to use g_dbus_connection_call_sync() on a just-in-time basis. The indentation is deliberately a bit odd here, to avoid a large diffstat from re-indentation; it will be fixed in a subsequent commit. Fixes: 69961f3 "openuri: Use FileManager1 in OpenDirectory" Resolves: #636 Signed-off-by: Simon McVittie <[email protected]>
|
Any chance to push out a new release including this fix? |
Why new version with this fix is not released yet ? |
Making a synchronous call into a GTK implementation of o.fd.FileManager1 can cause a deadlock, because GtkApplication makes a synchronous call into the Inhibit portal when started in a non-GNOME, non-XFCE environment. In this situation, each service does not take its bus name (and hence complete service-activation) until it gets a reply from the other, which obviously can't work. We don't actually need a GDBusProxy here: we don't need to subscribe to any signals, watch any properties or hold any state, so it's just as straightforward to use g_dbus_connection_call_sync() on a just-in-time basis. The indentation is deliberately a bit odd here, to avoid a large diffstat from re-indentation; it will be fixed in a subsequent commit. Fixes: 69961f3 "openuri: Use FileManager1 in OpenDirectory" Resolves: flatpak#636 Signed-off-by: Simon McVittie <[email protected]>
|
Can a new release with this fix be pushed out? This adds an artificial delay at system startup that's very annoying. |
Making a synchronous call into a GTK implementation of o.fd.FileManager1 can cause a deadlock, because GtkApplication makes a synchronous call into the Inhibit portal when started in a non-GNOME, non-XFCE environment. In this situation, each service does not take its bus name (and hence complete service-activation) until it gets a reply from the other, which obviously can't work. We don't actually need a GDBusProxy here: we don't need to subscribe to any signals, watch any properties or hold any state, so it's just as straightforward to use g_dbus_connection_call_sync() on a just-in-time basis. The indentation is deliberately a bit odd here, to avoid a large diffstat from re-indentation; it will be fixed in a subsequent commit. Fixes: 69961f3 "openuri: Use FileManager1 in OpenDirectory" Resolves: flatpak#636 Signed-off-by: Simon McVittie <[email protected]>
|
Is this fixed yet? I'm having similar problem. Installing flatpak package in arch linux (xmonad) slows down thunar startup time by 25-30s! Without flatpak installed startup time is only 2-3s. |
|
Still happening. Chromium flatpak takes 5 minutes to open after startup. Pop!_OS 22.04 (Gnome 42.9) |
|
#639 was included in 1.12.0 and all newer versions. @Mahrjose, @hyuri, you might be experiencing the same issue as #986 and #1024, rather than what was originally reported here. If so, xdg-desktop-portal 1.17.0 should resolve that. If you are experiencing a similar symptom with xdg-desktop-portal 1.17.0 or later, please open a separate issue with more information, such as the versions of relevant components that you are using (xdg-desktop-portal, any backends such as xdg-desktop-portal-gtk that you have installed) and the messages that appear in the systemd journal during the delay. |
As a result, several apps have to wait while the service was starting.
This starts happening when I updated to 1.10.1. Notice the time between the
Starting Portal serviceandStarted Portal service:The service started immediately in 1.8.1:
FYI I also use sway, so there might be some configuration problems.
Edit: I checked #607, but my xdg-desktop-portal-wlr seems to start up properly.
The text was updated successfully, but these errors were encountered: