Slow launch for (some) GTK apps

[tokyovigilante]

• Sway Version:

  • sway version 1.5-d6ac3075 (Oct 13 2020, branch 'master')

• Debug Log:
  https://gist.github.com/tokyovigilante/198fe1b11f378bc02b9c41b14396cf18

• Configuration File:
  Minimal - https://gist.github.com/tokyovigilante/1222534c8743c1827933fe4d3cbd6d38

• Description:
  Launching some GTK/GLib apps seems to hang for ~10-15 sec before launching and running normally. Occurs at least with waybar, sublime-merge and Pantheon files app. Doesn't happen with Vivaldi, ST3 or terminal (alacritty). Nothing obvious in the log, all affected apps should be Wayland-native. 100% reproducible with affected apps.

Log shows launch to minimal desktop, followed by waybar appearing at ~15 sec as a result of being called from bar_command.

Lenovo X1Y4 with FC33, Kernel 5.9 and mesa-git, although also occuring on an Intel desktop with AMD GPU (also using mesa-git).

[Xyene]

Can you run strace -tt -ff [some GTK app] and upload the resulting logs somewhere? That might give an indication of where the application is waiting.

[emersion]

Heard on IRC that adding exec systemctl --user import-environment to the config file helped with that for some reason...

[Vorsplummi]

Heard on IRC that adding exec systemctl --user import-environment to the config file helped with that for some reason...

Thanks for that. This issue came out of nowhere. So far Fedora has been the only distro I've tested that has this problem.

[wmww]

This might be related to the switch from wayland-0 to wayland-1? I solved something like this by putting a *.conf file in ~/.config/environment.d containing WAYLAND_DISPLAY=wayland-1.

Edit: try systemctl --user status xdg-desktop-portal.service. If that service failed with an error relating to the Wayland display, then that's you're problem. Specifically, GTK is trying to use the service here and it's failing, with a long timeout.

[tokyovigilante]

@wmww Sure looks that way:

● xdg-desktop-portal.service - Portal service
     Loaded: loaded (/usr/lib/systemd/user/xdg-desktop-portal.service; static)
     Active: failed (Result: timeout) since Wed 2020-10-14 08:13:45 NZDT; 7h ago
    Process: 4175 ExecStart=/usr/libexec/xdg-desktop-portal (code=killed, signal=TERM)
   Main PID: 4175 (code=killed, signal=TERM)
        CPU: 41ms

Oct 14 08:12:15 crackotage systemd[3828]: Starting Portal service...
Oct 14 08:13:05 crackotage xdg-desktop-por[4175]: Failed to create settings proxy: Error calling StartServiceByName for org.freedesktop.impl.portal.desktop.gtk: Timeout was reached
Oct 14 08:13:30 crackotage xdg-desktop-por[4175]: Failed to create file chooser proxy: Error calling StartServiceByName for org.freedesktop.impl.portal.desktop.gtk: Timeout was reached
Oct 14 08:13:30 crackotage xdg-desktop-por[4175]: No skeleton to export
Oct 14 08:13:45 crackotage systemd[3828]: xdg-desktop-portal.service: start operation timed out. Terminating.
Oct 14 08:13:45 crackotage systemd[3828]: xdg-desktop-portal.service: Failed with result 'timeout'.
Oct 14 08:13:45 crackotage systemd[3828]: Failed to start Portal service.

Neither adding the environment variable, nor exec systemctl --user import-environment have seemed to help however.

Here's a strace log from launching pavucontrol, noting the jump from 15:22:42 -> 15:22:57 and then to 15:23:07.

https://gist.github.com/tokyovigilante/872e9e24c061886ab19a14f9ae19ad3c

[wmww]

If you've established that xdg-desktop-portal.service is broken, then there's no mystery as to why GTK apps are slow to start. GTK hits the org.freedesktop.portal.Desktop on the dbus session bus. If that fails, it blocks here. You can also test this by using d-feet and looking for that name in the session bus. If the service is broken and you click it it will spin for a while and then throw up an error message (pretty sure this will happen, since you already established the systemd service is failing).

As for how to fix it, I'm not sure. You can try running /usr/libexec/xdg-desktop-portal from the command line and see if that works. If it does, verify GTK apps can start faster with it running and narrow in on why it's failing when launched by systemd. If it doesn't, figure out why.

[tokyovigilante]

Was going to edit the above post, but thanks for the speedy reply. Mysteriously fixed after a reboot with both fixes above applied. Are these true fixes and I can close this, or is there an underlying sway bug?

[wmww]

Ah yes, you'd need to reboot (or maybe just restart the session?) for the ~/.config/environment.d/something.conf file to take effect. I'm not sure Sway can do anything about this except switch back to wayland-0 (which I assume isn't up for consideration). I'd leave open it and let @emersion close it if there's nothing more to add.

[Emantor]

FWIW the very end in my sway file runs exec "systemctl --user import-environment SWAYSOCK WAYLAND_DISPLAY; to ensure that my units see the correct $WAYLAND_DISPLAY. However this obviously breaks multi session logins of the same user, since my systemd user units will only ever work with the last started sway compositor.

[emersion]

Note that because some distributions ship by default a similar script for X11, that explains why we're the only ones seeing this.

https://github.com/systemd/systemd/blob/dfc637d0ff756889e8e5b7cb4ec991eb06069aa1/xorg/50-systemd-user.sh

Some systemd distributions like Arch Linux ship something similar by default:

https://github.com/archlinux/svntogit-community/blob/a334964ae6210e6dcbe5db094d51d7c27e6f89b0/trunk/50-systemd-user.conf

Obviously it's not included by default in user config files.

I don't think there's much to be done here. I added a wiki entry to document the issue: https://github.com/swaywm/sway/wiki#gtk-applications-take-20-seconds-to-start

[caleb-allen]

Adding exec systemctl --user import-environment to my config and restarting fixed this issue for me as well

[josteink]

Thanks for that. This issue came out of nowhere. So far Fedora has been the only distro I've tested that has this problem.

I just experienced this on Ubuntu 20.04 too just now, but I did so after adding a custom PPA for updated mesa-drivers, which may also be a contributing factor. Honestly not sure.

Solution was the same though, so I'm happy.

[beucismis]

Adding exec systemctl --user import-environment to my config and restarting fixed this issue for me as well

Is there a method for nosystemd? For example OpenRC.

[TheodorRene]

This was still an issue for my system, and will probably be for others. Mostly default Ubuntu 22.04.1 LTS with Sway installed, fixed with exec systemctl --user import-environment in my config. Sway version 1.7

[eternal-sorrow]

For me adding exec systemctl --user import-environment did not help. I guess it's because xdg-desktop-portal-gtk starts too early in my case, before the import took place. So I did systemctl --user edit xdg-desktop-portal-gtk.service and added Restart=on-failure in the [Service] section of the unit. Now it restarts several times before the environment is imported and then the unit starts successfully.

[beucismis]

But what if it uses no-systemd?

[eternal-sorrow]

@beucismis does xdg-desktop-portal work without systemd at all? Maybe you better set GTK_USE_PORTAL=0?

[tchofy]

I'm on Hyprland, was having the same issues and fixed them by following their wiki, however, some GTK apps were still having the 25s timeout (Firefox and Virt-Manager, for me), even with GTK_USE_PORTAL=0, and I couldn't get much relevant information from journalctl, but thankfully I ran into this blog post, and gnome-keyring-daemon was the root cause of my secondary issue.

[IGLOU-EU]

Same for me and adding exec systemctl --user import-environment not fix. But removing xdg-desktop-portal-gnome fix it ! I don't use sandboxed app.

[MichaelSasser]

I had the same issue. I tried everything in the wiki and the recommendations from this issue. Unfortunately, nothing helped besides removing xdg-desktop-portal.

Later on, I figured out that I had some other portal backends installed like xdg-desktop-portal-gtk. After I removed every package that started with xdg-desktop-portal- and xdg-desktop-portal I installed xdg-desktop-portal-wlr again, which installed xdg-desktop-portal as dependency, everything worked. Besides that, I only have include /etc/sway/config.d/* in my sway config, which currently includes the file /etc/sway/config.d/50-systemd-user.conf containing the following two lines.

exec systemctl --user import-environment DISPLAY WAYLAND_DISPLAY SWAYSOCK XDG_CURRENT_DESKTOP
exec hash dbus-update-activation-environment 2>/dev/null && \
     dbus-update-activation-environment --systemd DISPLAY WAYLAND_DISPLAY SWAYSOCK XDG_CURRENT_DESKTOP

I'm uncertain if the file is available on every distribution, so check that first, i.e., using cat /etc/sway/config.d/* which should print them. If not, just put them in your sway config instead of the include ... line.

[duzda]

Not using sway, but ran into similar issue, as opposed to Michael, I didn't have to get rid of all xdg-desktop-portal packages, only had to get rid of xdg-desktop-portal-gnome, which fixed the issue.

[tim-harding]

xdg-desktop-portal-gnome was the culprit for me as well.