Bugzilla – Bug 1210065
GTK outside GNOME starts super slow any window
Last modified: 2023-07-01 04:38:24 UTC
Created attachment 866073 [details] XDG env variables without pri-loging in gnome I have gnome installed but i use awesomewm for years. After recent updates I noticed that GTK windows may take even 5 to 10minutes to open. The least is always over 1-2 minutes. Since i do not use much of gtk apps, i can not tell when exactly this behavior started. I try to fix this for days. I corrected my awesomewm to autostart the XDG/autostart *.desktop files (at least the important ones). I fixed .Xresources too. On awesome i see gnome-keyring running and gsd-xsettings too. (I used xsettingsd too with no luck). I use gdm (neither xdm make a difference). The strange thing is that if i login in gnome, logout and login to awesome, GTK apps open in seconds. This is a nice workaround. I compared active services on awesomewm and on awesome-after-gnome situations and found nothing interest. I wonder what gnome does and remains that fixes the problem of awesome with the GTK apps. I attach the printenv for XDG without previously logging in gnome. If i login gnome, logoff and login awesome the same variables are XDG_CONFIG_DIRS=/etc/xdg:/usr/local/etc/xdg:/usr/etc/xdg XDG_SEAT=seat0 XDG_SESSION_DESKTOP=awesome XDG_SESSION_TYPE=x11 XDG_SESSION_CLASS=user XDG_VTNR=2 XDG_SESSION_ID=2 XDG_RUNTIME_DIR=/run/user/1000 XDG_DATA_DIRS=/home/jimishol/.local/share/flatpak/exports/share:/var/lib/flatpak/exports/share:/usr/local/share/:/usr/share/ I exported the 2 missing variables without success too. An other difference is that in gnome-awesomewm sequence, a /run/user/1000/ICEauthority file is present. This file is not present if i login in awesome directly, without visiting gnome first. A nicer fix or workaround would be very nice and great help to me. Thank you.
The stuck smells like some dependency user based service was called after a certain timeout or so. Can you please attach the initial process lists respectively: 1. Login through gdm -> awsomewm, gather the result of "ps aux" without launching any gtk applications 2. Login through gdm -> GNOME -> Logout -> awsomewm, gather the result of "ps aux" without launching any gtk applications
Few things to add. I created a "test" user by yast module with no success. So, it is independent from user's configurations. When ICEauthority misses the bug occurs. If ICEauthority is present windows open fast. The only way to have ICEauthority present is, while in gnome, to check directory tree as user. So, in my case, I open terminal and run vifm. No matter if i close or not the terminal window, when i logoff and log in awesomewm The ICEauthority remains in place and all are ok. If i do not run the vifm and logoff from gnome, ICEauthority disappears. An other way is while in gdm to open tty3 and run vifm there. Then go back to gdm (at tty7) login to gnome and logoff, without need to run vifm in gnome too. Loging in awesome ICEauthority remains and all is ok. Comparing the sorted output of ps aux, i noticed the folowwing 2 process are missing when ICEauthority is not present (the case where i did not visted gnome first) xdg-desktop-portal-gnome xdg-desktop-portal-gtk In that case, i see in journalctl that these 2 systemd services fail. I attach the output of ps aux.
Created attachment 866090 [details] ps aux on fail, unsorted
Created attachment 866091 [details] ps aux on fail sorted
Created attachment 866092 [details] ps aux with ICEauthority present, unsorted Where gtk windows open fast.
Created attachment 866093 [details] ps aux when ICEauthority is present, sorted gtk windows open fast.
I think i solved it. If the solution seems right to you, please mark this bug as closed. ICEauthority file seems irrelevant now. I added one line in /etc/X11/xinit/xinitrc.d/xdg-user-dirs.sh file, so it reads as #!/bin/sh systemctl --user import-environment /usr/bin/xdg-user-dirs-update GTK windows opens fast now (despite ICEauthority is not present). I added the 2nd line of the above (systemctl...). Thank you
My previous solution seems BAD. It works on my laptop that has only 1 user who has to login to session. It does NOT work on my tumbleweed desktop that has many users, where one of them autologins in gnome. I spent half of my night trying to fix this and i noticed the following. 1) The option "--user" i gave in systemctl command, seems out of place in /etc/X11/xinit/xinitrc.d/xdg-user-dirs.sh file. 2) the execution of that command displays that i should not use it without parameters. 3) the same command exists in /usr/etc/X11/xinit/xinitrc.d/50-systemd-user.sh, so my solution should not be necessary. 4) My solution is not enough on my identical system on desktop. I usually trust defaults and do not mess with installation on these two systems that I regularly use every day. I made an exception on awesomewm though and installed awesome-branding-upstream instead of the default awesome-branding-openSUSE. I cannot find the bug or report i made but i had similar behavior as 1152601 bug, only in my case openSUSE used a deprecated widget for calendar or something.
> It does NOT work on my tumbleweed desktop that has many users, where one of > them autologins in gnome. Interesting, how did the steps look like to see the problem? > 3) the same command exists in /usr/etc/X11/xinit/xinitrc.d/50-systemd-user.sh This imports DISPLAY and XAUTHORITY, which is probably not enough to make the xdg-desktop-portal-* services wholly happy. I did not have a chance to dig deeper yet, while the overall status sounds subtle - xdg-desktop-portal-gtk or xdg-desktop-portal-gnome may be in a tangled status that causes a long freeze when gtk applications wait for the dbus interface. The real reason may be scattered somewhere in the portal implementations. Maybe we can just try to remove xdg-desktop-portal-gnome without changing anything else, and try how it looks. It will at least narrow down the area a bit.
I finally, after all day tries, fixed my desktop too. I believe the solution is still bad in design but nevertheless it works. I farther edited the /etc/X11/xinit/xinitrc.d/xdg-user-dirs.sh file. My laptop did not need the third row but i added it anyway on both tumbleweed systems. Now /etc/X11/xinit/xinitrc.d/xdg-user-dirs.sh looks like #!/bin/sh systemctl --user import-environment /usr/bin/xdg-user-dirs-update systemctl restart polkit That's it. Thank you
Unfortunately after recent updates my workaround does not work anymore. Neither the login first in gnome works this time. I summarize: * gtk windows as gnome-calculator AND qt6 as telegram-desktop take 1 to 3 minutes to open. * yast2, mpv,vlc open fast. * new user face the sane problem. * lightdm and gdm face the same problem * awesomewm and ICEwm face the same problem * only gnome does something that no one else do and open all windows fast I run journalctl -xe|grep failed I got the attached files. I give up for the time being
Created attachment 866624 [details] failed lines from awesomewm
Created attachment 866625 [details] failed lines from gnome
(In reply to Jimis Hol from comment #11) > Unfortunately after recent updates my workaround does not work anymore. > Neither the login first in gnome works this time. I summarize: > * gtk windows as gnome-calculator AND qt6 as telegram-desktop take 1 to 3 > minutes to open. > * yast2, mpv,vlc open fast. > * new user face the sane problem. > * lightdm and gdm face the same problem > * awesomewm and ICEwm face the same problem > * only gnome does something that no one else do and open all windows fast Jimis, did you have a chance to try to remove xdg-desktop-portal-gnome mentioned in the comment#9?
> Jimis, did you have a chance to try to remove xdg-desktop-portal-gnome > mentioned in the comment#9? I thought that xdg-desktop-portal-gnome was essential and was installed by gnome as dependency, so you were talking about opensuse to remove it, not me. Anyway i did not know what i does and if i, or gnome, actually need it. First thing in the morning was to check my emails in the hope you were commented my post. I opened up evolution client to check and i faced the symptom that made me first to realize that there was a problem. I saw your email, i opened it but the content of it was refuse to be rendered immediately. If i waited 5 minutes or so it should be rendered and could eventually read it. Instead i removed xdg-desktop-portal-gnome immediately and, needed or not, rebooted. Almost in tears i realized that problem solved ! Yes that narrows the area a bit. !! Thank you so much !!!
Sorry for the double comment that i can not remove. I had a network failure and in bugzilla prompt i choosed to submit only my comment, without understanding that the other who commented was actually me. Anyway I connected to my desktop and removed the xdg-desktop-portal-gnome from terminal by zypper. I saw the following output that might be interesting. The unit files have no installation config (WantedBy=, RequiredBy=, Also=, Alias= settings in the [Install] section, and DefaultInstance= for template units). This means they are not meant to be enabled or disabled using systemctl. Possible reasons for having this kind of units are: * A unit may be statically enabled by being symlinked from another unit's .wants/ or .requires/ directory. * A unit's purpose may be to act as a helper for some other unit which has a requirement dependency on it. * A unit may be started when needed via activation (socket, path, timer, D-Bus, udev, scripted systemctl call, ...). * In case of template units, the unit is meant to be enabled with some instance name specified.
(In reply to Jimis Hol from comment #15) > > Jimis, did you have a chance to try to remove xdg-desktop-portal-gnome > > mentioned in the comment#9? > Instead i removed xdg-desktop-portal-gnome immediately and, needed or not, > rebooted. > > Almost in tears i realized that problem solved ! Great, at least we have a workable environment :-) The xdg-desktop-portal-gnome literally meant to be used in GNOME desktop environment, so it is installed when GNOME desktop is installed. While I suspect it is really needed by awesome wm in most cases.
I am having a lot of trouble with this bug. It keeps me from loading a systemd user service that does some D-Bus stuff and shows a zenity dialog window. I thought I was doing something wrong until I found all these different bug reports about xdg-desktop-portal-gnome. The problem has been affecting me on multiple distros, but it's been particularly problematic on openSUSE Tumbleweed with the KDE desktop. Doesn't seem like there is any good solution other than uninstalling xdg-desktop-portal-gnome, or masking the service, but those solutions may cause issues with logging into GNOME on the same system. This seems to have been at least partially fixed on Ubuntu and Fedora at this point. The fact that there's no apparent action on this is unfortunate.