Sway Version:
sway version 1.5-d6ac3075 (Oct 13 2020, branch 'master')
Debug Log:
https://gist.github.com/tokyovigilante/198fe1b11f378bc02b9c41b14396cf18Configuration File:
Minimal - https://gist.github.com/tokyovigilante/1222534c8743c1827933fe4d3cbd6d38Description:
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).
tokyovigilante
All 12 comments
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.
Xyene
on 13 Oct 2020
Heard on IRC that adding exec systemctl --user import-environment to the config file helped with that for some reason...
emersion
on 13 Oct 2020
Heard on IRC that adding
exec systemctl --user import-environmentto 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.
Vorsplummi
on 13 Oct 2020
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.
wmww
on 13 Oct 2020
@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
tokyovigilante
on 14 Oct 2020
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.
wmww
on 14 Oct 2020
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?
tokyovigilante
on 14 Oct 2020
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.
wmww
on 14 Oct 2020
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.
Emantor
on 14 Oct 2020
Note that because some distributions ship by default a similar script for X11, that explains why we're the only ones seeing this.
Some systemd distributions like Arch Linux ship something similar by default:
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
emersion
on 14 Oct 2020
Adding exec systemctl --user import-environment to my config and restarting fixed this issue for me as well
caleb-allen
on 21 Nov 2020
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.
josteink
on 3 Dec 2020
Related issues
ddevault
·
4Comments
ddevault
·
3Comments
RyanDwyer
·
3Comments
emersion
·
4Comments
marcoms
·
3Comments
Most helpful comment
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?