All GTK programs take a long time to start since latest snapshot
Hi, Here's a weird one. Since I upgraded to snapshot 20230823, on my system, if I try to start any program that uses GTK (Firefox, deadbeef, gedit, ...), program is stuck early on startup (way before any UI is displayed) timeouting on a poll() call that as a 25s timeout. I added my observations (with strace output) to an existing previous bug report that was for Firefox: https://bugzilla.opensuse.org/show_bug.cgi?id=1214043 https://old.reddit.com/r/openSUSE/comments/15jygg0/slow_firefox_startup/ This must not be a frequent issue since I did not see it reported by anyone other than the user of above link. My TW installation is 4 years old, root filesystem is btrfs, /home is XFS. Any idea what this could be causing this ?
Hello, I have yet to upgrade to the latest snapshot (and I'm on Aeon so perhaps things are slightly different), but usually for glib/gtk applications you can try with setting the G_MESSAGES_DEBUG env to "all" to get some more verbose output: G_MESSAGES_DEBUG=all gedit Hope it helps! Eugenio On Fri, 2023-08-25 at 11:21 +0200, Michael Pujos wrote:
Hi,
Here's a weird one.
Since I upgraded to snapshot 20230823, on my system, if I try to start any program that uses GTK (Firefox, deadbeef, gedit, ...), program is stuck early on startup (way before any UI is displayed) timeouting on a poll() call that as a 25s timeout. I added my observations (with strace output) to an existing previous bug report that was for Firefox:
https://bugzilla.opensuse.org/show_bug.cgi?id=1214043 https://old.reddit.com/r/openSUSE/comments/15jygg0/slow_firefox_startup/
This must not be a frequent issue since I did not see it reported by anyone other than the user of above link.
My TW installation is 4 years old, root filesystem is btrfs, /home is XFS.
Any idea what this could be causing this ?
On Friday 2023-08-25 11:21, Michael Pujos wrote:
Since I upgraded to snapshot 20230823, on my system, if I try to start any program that uses GTK (Firefox, deadbeef, gedit, ...), program is stuck early on startup (way before any UI is displayed) timeouting on a poll() call that as a 25s timeout.
25 is a magic number pointing to dbus as the culprit. (The internet is full of those reports.)
Op vrijdag 25 augustus 2023 11:35:11 CEST schreef Jan Engelhardt:
On Friday 2023-08-25 11:21, Michael Pujos wrote:
Since I upgraded to snapshot 20230823, on my system, if I try to start any program that uses GTK (Firefox, deadbeef, gedit, ...), program is stuck early on startup (way before any UI is displayed) timeouting on a poll() call that as a 25s timeout.
25 is a magic number pointing to dbus as the culprit. (The internet is full of those reports.)
I have this 25 seconds delay twice when using kwalletmanager5, but it is the only one giving this delay. I found this using strace and reported it in a bug report on bugs.kde.org. -- fr.gr. member openSUSE Freek de Kruijf
Mystery solved. uninstalling the xdg-desktop-portal-gnome package fixed it. Basically caused by my unusual setup. Longer explanation on https://bugzilla.opensuse.org/show_bug.cgi?id=1214043 On 8/25/23 11:41, Freek de Kruijf wrote:
Op vrijdag 25 augustus 2023 11:35:11 CEST schreef Jan Engelhardt:
On Friday 2023-08-25 11:21, Michael Pujos wrote:
Since I upgraded to snapshot 20230823, on my system, if I try to start any program that uses GTK (Firefox, deadbeef, gedit, ...), program is stuck early on startup (way before any UI is displayed) timeouting on a poll() call that as a 25s timeout. 25 is a magic number pointing to dbus as the culprit. (The internet is full of those reports.) I have this 25 seconds delay twice when using kwalletmanager5, but it is the only one giving this delay. I found this using strace and reported it in a bug report on bugs.kde.org.
On Fri, Aug 25, 2023 at 1:44 PM Michael Pujos <pujos.michael@gmail.com> wrote:
Mystery solved.
uninstalling the xdg-desktop-portal-gnome package fixed it.
Unfortunately that is where every other report on the Internet stops as well. I have yet to see any explanation, *why* timeout occurs.
On 8/25/23 13:01, Andrei Borzenkov wrote:
On Fri, Aug 25, 2023 at 1:44 PM Michael Pujos <pujos.michael@gmail.com> wrote:
Mystery solved.
uninstalling the xdg-desktop-portal-gnome package fixed it.
Unfortunately that is where every other report on the Internet stops as well. I have yet to see any explanation, *why* timeout occurs.
I do not know the exact details, but I believe this is what happens when xdg-desktop-portal-gnome is installed: - on app startup, whatever GNOME specific code detects that xdg-desktop-portal-gnome is installed and attempts to connect to its D-BUS interface - if xdg-desktop-portal-gnome.service failed to start for whatever reason (system not being into graphical-session.target i my case), it timeouts after 25s. Now the question is why it uses such a long timeout and if this situation could be improved. Basically, anybody not using a Desktop Manager (I know, this is not really supported, but still...) to start Xorg (and probably Wayland) is screwed if xdg-desktop-portal-gnome is installed, or if it is installed an not manually starting /usr/libexec/xdg-desktop-portal-gnome in startup scripts (~/.xprofile). Possibly only in the case of not using GNOME as a DE. Also what's questionable is why xdg-desktop-portal-gnome was suddenly installed on my system in an update, while it never was for 4 years.
On Fri, Aug 25, 2023 at 2:18 PM Michael Pujos <pujos.michael@gmail.com> wrote:
On 8/25/23 13:01, Andrei Borzenkov wrote:
On Fri, Aug 25, 2023 at 1:44 PM Michael Pujos <pujos.michael@gmail.com> wrote:
Mystery solved.
uninstalling the xdg-desktop-portal-gnome package fixed it.
Unfortunately that is where every other report on the Internet stops as well. I have yet to see any explanation, *why* timeout occurs.
I do not know the exact details, but I believe this is what happens when xdg-desktop-portal-gnome is installed:
- on app startup, whatever GNOME specific code detects that xdg-desktop-portal-gnome is installed and attempts to connect to its D-BUS interface - if xdg-desktop-portal-gnome.service failed to start for whatever reason
And the reason for this failure is never explained anywhere.
(system not being into graphical-session.target i my case), it timeouts after 25s.
Of course, that was not the question. I was not clear enough. IIRC 25s is the internal timeout inside glib.
Also what's questionable is why xdg-desktop-portal-gnome was suddenly installed on my system in an update, while it never was for 4 years.
zypper search --requires-pkg zypper search --recommends-pkg zypper info --supplements are your friends.
On 8/25/23 20:58, Andrei Borzenkov wrote:
On Fri, Aug 25, 2023 at 2:18 PM Michael Pujos <pujos.michael@gmail.com> wrote:
On 8/25/23 13:01, Andrei Borzenkov wrote:
On Fri, Aug 25, 2023 at 1:44 PM Michael Pujos <pujos.michael@gmail.com> wrote:
Mystery solved.
uninstalling the xdg-desktop-portal-gnome package fixed it.
Unfortunately that is where every other report on the Internet stops as well. I have yet to see any explanation, *why* timeout occurs.
I do not know the exact details, but I believe this is what happens when xdg-desktop-portal-gnome is installed:
- on app startup, whatever GNOME specific code detects that xdg-desktop-portal-gnome is installed and attempts to connect to its D-BUS interface - if xdg-desktop-portal-gnome.service failed to start for whatever reason
And the reason for this failure is never explained anywhere.
https://gitlab.gnome.org/GNOME/gtk/-/issues/4830
(system not being into graphical-session.target i my case), it timeouts after 25s.
Of course, that was not the question. I was not clear enough.
IIRC 25s is the internal timeout inside glib.
Also what's questionable is why xdg-desktop-portal-gnome was suddenly installed on my system in an update, while it never was for 4 years.
I had a similar issue, with the enlightenment desktop and switching to dbus-broker fixed it for me, given its now not isolated to my less then usual setup I think its good motivation for me to switch dbus-broker to the default. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B
And the reason for this failure is never explained anywhere.
So unraveling the spaghetti, it looks like a misunderstanding between systemd and D-BUS about the failure of the service to start, not a GNOME/GTK issue. Hope a proper solution will be found, with apparently recent progress.
On 8/25/23 13:28, Andrei Borzenkov wrote:
zypper search --requires-pkg zypper search --recommends-pkg zypper info --supplements
are your friends.
Thanks. With 'zypper info --supplements', I understood how I got xdg-desktop-portal-gnome installed. It is when I manually installed flatpak a few days ago (thus it has nothing to do with a 'zypper dup'). Installing flatpak installs xdg-desktop-portal-gnome because of: Supplements : (gnome-shell and (flatpak or snapd)) In the output of 'zypper info --supplements xdg-desktop-portal-gnome'. Thus it is equivalent as if flatpak had xdg-desktop-portal-gnome as Recommends. Hence the question, should flatpak and snapd install xdg-desktop-portal-gnome ?
On 25.08.2023 15:39, Michael Pujos wrote:
On 8/25/23 13:28, Andrei Borzenkov wrote:
zypper search --requires-pkg zypper search --recommends-pkg zypper info --supplements
are your friends.
Thanks.
With 'zypper info --supplements', I understood how I got xdg-desktop-portal-gnome installed. It is when I manually installed flatpak a few days ago (thus it has nothing to do with a 'zypper dup').
Installing flatpak installs xdg-desktop-portal-gnome because of:
Supplements : (gnome-shell and (flatpak or snapd))
In the output of 'zypper info --supplements xdg-desktop-portal-gnome'.
Thus it is equivalent as if flatpak had xdg-desktop-portal-gnome as Recommends.
No, it is not.
Hence the question, should flatpak and snapd install xdg-desktop-portal-gnome ?
Well ... - flatpak (and snapd) most certainly needs xdg-desktop-portal. After all, XDP is created by flatpak. Without it you probably get rather crippled functionality. So /some/ implementation of XDP backend has to be present. - if user is using GNOME, it is just natural to use XDP backend that integrates into GNOME. The fact that gnome-shell is installed can be considered as a strong hint that user intends to use GNOME. So from the distribution point of view this Supplements is pretty much correct. The practical problem is that this information is static. Even if user mostly works with GNOME, user still may log in into different desktop occasionally. There could be other users using different desktop. Until recently XDP did not offer any way to influence which backend gets used. This changed in xdg-dekstop-portal 1.17 where you can disable specific portals or interfaces from these portals per desktop and also globally or per-user. https://github.com/flatpak/xdg-desktop-portal/issues/906#issuecomment-134297... That said, we still have no idea why xdg-desktop-portal-gnome fails to start for you. The bug mentioned by Simon was the result of the wrong configuration (incorrect environment in systemd user instance). If this happens in your case, there is a bug somewhere that needs to be fixed. Removing xdg-desktop-portal-gnome just hides this bug.
With 'zypper info --supplements', I understood how I got xdg-desktop-portal-gnome installed. It is when I manually installed flatpak a few days ago (thus it has nothing to do with a 'zypper dup').
Installing flatpak installs xdg-desktop-portal-gnome because of:
Supplements : (gnome-shell and (flatpak or snapd))
In the output of 'zypper info --supplements xdg-desktop-portal-gnome'.
Thus it is equivalent as if flatpak had xdg-desktop-portal-gnome as Recommends.
No, it is not.
How is it different ? As I understand it, "Supplements" is a reverse "Recommends". In any case, that "Supplements" causes xdg-desktop-portal-gnome to be installed when flatpak (or snapd) is installed, as if xdg-desktop-portal-gnome was a recommend of flatpak.
Hence the question, should flatpak and snapd install xdg-desktop-portal-gnome ?
Well ...
- flatpak (and snapd) most certainly needs xdg-desktop-portal. After all, XDP is created by flatpak. Without it you probably get rather crippled functionality. So /some/ implementation of XDP backend has to be present.
- if user is using GNOME, it is just natural to use XDP backend that integrates into GNOME. The fact that gnome-shell is installed can be considered as a strong hint that user intends to use GNOME.
So from the distribution point of view this Supplements is pretty much correct.
The practical problem is that this information is static. Even if user mostly works with GNOME, user still may log in into different desktop occasionally. There could be other users using different desktop. Until recently XDP did not offer any way to influence which backend gets used. This changed in xdg-dekstop-portal 1.17 where you can disable specific portals or interfaces from these portals per desktop and also globally or per-user.
https://github.com/flatpak/xdg-desktop-portal/issues/906#issuecomment-134297...
That said, we still have no idea why xdg-desktop-portal-gnome fails to start for you. The bug mentioned by Simon was the result of the wrong configuration (incorrect environment in systemd user instance). If this happens in your case, there is a bug somewhere that needs to be fixed. Removing xdg-desktop-portal-gnome just hides this bug.
Thanks for the elaborate explanation. xdg-desktop-portal-gnome.service fails to start for me because I run my system in multi-user.target (not using a Desktop Manager and using startx) and xdg-desktop-portal-gnome.service depends on graphical-session.target, resulting in: Aug 25 12:02:39 p72 systemd[6676]: Dependency failed for Portal service (GNOME implementation). Aug 25 12:02:39 p72 systemd[6676]: xdg-desktop-portal-gnome.service: Job xdg-desktop-portal-gnome.service/start failed with result 'dependency'. I know that not using a Desktop Manager is not recommended and maybe not supported, so I'm ready to cope with some (rare) caveats like these.
Am 26.08.23 um 15:00 schrieb Michael Pujos:
With 'zypper info --supplements', I understood how I got xdg-desktop-portal-gnome installed. It is when I manually installed flatpak a few days ago (thus it has nothing to do with a 'zypper dup').
Installing flatpak installs xdg-desktop-portal-gnome because of:
Supplements : (gnome-shell and (flatpak or snapd))
In the output of 'zypper info --supplements xdg-desktop-portal-gnome'.
Thus it is equivalent as if flatpak had xdg-desktop-portal-gnome as Recommends.
No, it is not.
How is it different ? As I understand it, "Supplements" is a reverse "Recommends". In any case, that "Supplements" causes xdg-desktop-portal-gnome to be installed when flatpak (or snapd) is installed, as if xdg-desktop-portal-gnome was a recommend of flatpak.
You have to parse the whole line. It only takes effect if gnome-shell is installed and flatpak or snapd are installed. So it is equivalent to flatpak, or snapd having Recommends: (xdg-desktop-portal-gnome if gnome-shell) or gnome-shell having Recommends: (xdg-desktop-portal-gnome if (flatpak or snapd)) - Ben
On Fri, 25 Aug 2023 14:28:00 +0300, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
On Fri, Aug 25, 2023 at 2:18 PM Michael Pujos <pujos.michael@gmail.com> wrote:
Also what's questionable is why xdg-desktop-portal-gnome was suddenly installed on my system in an update, while it never was for 4 years.
zypper search --requires-pkg zypper search --recommends-pkg zypper info --supplements
are your friends.
What is the meaning of "supplement(s)"? None of the man pages for zypper and rpm* define or describe it. Here is the output of 'grep -i supplement' for the ones that have it: === man zypper --supplements Show symbols the package supplements. --supplements Search for packages which supplement the search strings. --supplements-pkg Search for all packages that supplement any of the provides of === man rpm mends CAPABILITY] [--whatsuggests CAPABILITY] [--whatsupplements CAPA- [--recommends] [-R,--requires] [--suggests] [--supplements] --whatsupplements CAPABILITY Query all packages that supplement CAPABILITY. --supplements List capabilities supplemented by package(s) -- Robert Webb
On 26.08.2023 00:26, Robert Webb via openSUSE Factory wrote:
On Fri, 25 Aug 2023 14:28:00 +0300, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
On Fri, Aug 25, 2023 at 2:18 PM Michael Pujos <pujos.michael@gmail.com> wrote:
Also what's questionable is why xdg-desktop-portal-gnome was suddenly installed on my system in an update, while it never was for 4 years.
zypper search --requires-pkg zypper search --recommends-pkg zypper info --supplements
are your friends.
What is the meaning of "supplement(s)"?
https://rpm-software-management.github.io/rpm/manual/dependencies.html
None of the man pages for zypper and rpm* define or describe it.
None of the man pages for zypper and rpm define "requires" or "recommends" either, but you somehow are comfortable with it?
On 2023-08-26 00:21:31 Andrei Borzenkov wrote:
On 26.08.2023 00:26, Robert Webb via openSUSE Factory wrote:
On Fri, 25 Aug 2023 14:28:00 +0300, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
On Fri, Aug 25, 2023 at 2:18 PM Michael Pujos <pujos.michael@gmail.com> wrote:
Also what's questionable is why xdg-desktop-portal-gnome was suddenly installed on my system in an update, while it never was for 4 years.
zypper search --requires-pkg zypper search --recommends-pkg zypper info --supplements
are your friends.
What is the meaning of "supplement(s)"?
https://rpm-software-management.github.io/rpm/manual/dependencies.html
None of the man pages for zypper and rpm* define or describe it.
None of the man pages for zypper and rpm define "requires" or "recommends" either, but you somehow are comfortable with it?
"Requires" and "recommends" are self-defining, but "supplements" is rather ambiguous. Leslie -- Platform: Linux Distribution: openSUSE Leap 15.4 - x86_64
On 26.08.2023 11:19, J Leslie Turriff wrote:
None of the man pages for zypper and rpm define "requires" or "recommends" either, but you somehow are comfortable with it?
"Requires" and "recommends" are self-defining, but "supplements" is rather ambiguous.
"Requires" and "Recommends" are opaque tokens that define behavior of a software that is using them. Deducing behavior of the software from their meaning in English language is fallacy.
On Sat, 26 Aug 2023 08:21:31 +0300, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
On 26.08.2023 00:26, Robert Webb via openSUSE Factory wrote:
On Fri, 25 Aug 2023 14:28:00 +0300, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
zypper search --requires-pkg zypper search --recommends-pkg zypper info --supplements
What is the meaning of "supplement(s)"?
https://rpm-software-management.github.io/rpm/manual/dependencies.html
Thank you. I remember reading the 'Weak dependencies' section before, but had forgotten it. So, package A containing "Recommends: B" declares the same dependency relationship as package B containing "Supplements: A". Except that /etc/zypp/zypp.conf contains a variable controlling whether the Recommends dependencies are active or not. Are the Supplements dependencies always enabled?
None of the man pages for zypper and rpm* define or describe it.
None of the man pages for zypper and rpm define "requires" or "recommends" either, but you somehow are comfortable with it?
:-) "Requires" is used frequently when discussing dependencies, so it gets defined somewhat by context. "Recommends" has text describing the zypper options for it and the enabling setting in zypp.conf, and there has been discussion about it in this list. The 'Package Dependencies' section of the zypper man page does say they both are types of dependencies, but doesn't mention "Supplements" (or "Suggests", or "Enhances"). -- Robert Webb
On 26.08.2023 12:50, Robert Webb via openSUSE Factory wrote:
On Sat, 26 Aug 2023 08:21:31 +0300, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
On 26.08.2023 00:26, Robert Webb via openSUSE Factory wrote:
On Fri, 25 Aug 2023 14:28:00 +0300, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
zypper search --requires-pkg zypper search --recommends-pkg zypper info --supplements
What is the meaning of "supplement(s)"?
https://rpm-software-management.github.io/rpm/manual/dependencies.html
Thank you. I remember reading the 'Weak dependencies' section before, but had forgotten it.
So, package A containing "Recommends: B" declares the same dependency relationship as package B containing "Supplements: A". Except that /etc/zypp/zypp.conf contains a variable controlling whether the Recommends dependencies are active or not. Are the Supplements dependencies always enabled?
No, they are disabled by solver.onlyRequires too.
None of the man pages for zypper and rpm* define or describe it.
None of the man pages for zypper and rpm define "requires" or "recommends" either, but you somehow are comfortable with it?
:-) "Requires" is used frequently when discussing dependencies, so it gets defined somewhat by context. "Recommends" has text describing the zypper options for it and the enabling setting in zypp.conf, and there has been discussion about it in this list. The 'Package Dependencies' section of the zypper man page does say they both are types of dependencies, but doesn't mention "Supplements" (or "Suggests", or "Enhances").
Suggests and Enhances are just hints, they are never installed automatically and I am not sure whether zypper mentions them at all during normal run. I do not use YaST, so cannot comment on its interface.
On Sat, 26 Aug 2023 14:28:31 +0300, Andrei Borzenkov <arvidjaar@gmail.com> wrote:
On 26.08.2023 12:50, Robert Webb via openSUSE Factory wrote:
[...] Except that /etc/zypp/zypp.conf contains a variable controlling whether the Recommends dependencies are active or not. Are the Supplements dependencies always enabled?
No, they are disabled by solver.onlyRequires too.
Ah, that explains why it is not named "solver.ignoreRecommends". -- Robert Webb
Thanks for the pointer. I'm using i3 and some Googling mention this is needed for DBUS: dbus-update-activation-environment --systemd DBUS_SESSION_BUS_ADDRESS DISPLAY XAUTHORITY However, the script that start my i3 session already has this command, and manually running it in a shell does not fix the problem either. It is really weird as my setup worked properly for years, and this happens out of the blue. On 8/25/23 11:35, Jan Engelhardt wrote:
On Friday 2023-08-25 11:21, Michael Pujos wrote:
Since I upgraded to snapshot 20230823, on my system, if I try to start any program that uses GTK (Firefox, deadbeef, gedit, ...), program is stuck early on startup (way before any UI is displayed) timeouting on a poll() call that as a 25s timeout. 25 is a magic number pointing to dbus as the culprit. (The internet is full of those reports.)
participants (9)
-
Andrei Borzenkov -
Ben Greiner -
Eugenio Paolantonio -
Freek de Kruijf -
J Leslie Turriff -
Jan Engelhardt -
Michael Pujos -
Robert Webb -
Simon Lees