I recently noticed that when I try to open a new instance of Alacritty in Sway I would get a delay of ~16 seconds or more to open each instance.

Initially when I tried to look up issues related to this, I didn't find anything related in the Github project. There is now an issue for it though. I wasn't sure if it was Alacritty or something else at the time. So this post is more how I debugged and removed the delay, which could be applied to other instances.

All my packages were recently updated, so I couldn't depend on having to just update them. I did try to reset my local config for Alacritty to see if it might be something there. It had no effect on the issue--so I moved on.

In this next step, I used a helpful utility called strace. This tool allows me see system calls and signals returned to a specified process. Using the arguments tt for absolute timestamps and T for the duration each syscall takes, I could pass a command to test with additional arguments. In this case we are telling Alacritty to do nothing then exit.

strace -ttT alacritty -e false
Command I ran to debug Alacritty.

The output I got, snippet below, helped me clearly see the problem. Using the timestamp on the left hand side I scrolled through the output to find a big jump from 20:28:10 to 20:28:35. The syscall took 25 seconds! I could also see an error related to freedesktop after the jump in time as well.

20:28:10.095984 poll([{fd=22, events=POLLIN}, {fd=24, events=POLLIN}], 2, -1) = 1 ([{fd=24, revents=POLLIN}]) <25.026181>
20:28:35.122218 read(24, "Error org.freedesktop.DBus.Error", 32) = 32 <0.000009>
20:28:35.122258 read(24, ".NoReply: Did not receive a repl", 32) = 32 <0.000006>
20:28:35.122278 read(24, "y. Possible causes include: the "..., 64) = 64 <0.000005>
20:28:35.122432 read(24, "a reply, the message bus securit"..., 128) = 125 <0.000008>
Log showing the culprit syscall that was causing a delay.

From that information, I was able to find it might be related to systemd, so I opened journalctl to see the related logs. This led me to find the following warnings and errors.

Apr 07 20:27:54 archy xdg-desktop-por[3127]: GError set over the top of a previous GError or uninitialized memory.
                                             This indicates a bug in someone's code. You must ensure an error is NULL before it's set.
                                             The overwriting error message was: Error calling StartServiceByName for org.freedesktop.impl.portal.desktop.gtk: Timeout was reached
Apr 07 20:27:54 archy xdg-desktop-por[3127]: Failed to create settings proxy: Error calling StartServiceByName for org.freedesktop.impl.portal.desktop.gnome: Timeout was reached
Apr 07 20:27:54 archy xdg-desktop-por[3127]: No skeleton to export
Apr 07 20:28:09 archy systemd[3002]: xdg-desktop-portal.service: start operation timed out. Terminating.
Apr 07 20:28:09 archy systemd[3002]: xdg-desktop-portal.service: Failed with result 'timeout'.
Apr 07 20:28:09 archy systemd[3002]: Failed to start Portal service.
Log with xdg-desktop-portal services failing to start.

Doing some searching, I found I should have xdg-desktop-portal-wlr installed and setup for my system. What is wlr? That is wlroots, which is a Wayland compositor that Sway uses. Getting the package installed was simply using my package manager.

Then the setup for xdg-desktop-portal-wlr states if you use Sway then you can have the following line in your config file.

exec dbus-update-activation-environment --systemd WAYLAND_DISPLAY XDG_CURRENT_DESKTOP=sway
Configuration for for xdg-desktop-portal-wlr in the Sway config file.

Just to compare the before and after, If I use the following command:

strace -wc alacritty -e false
Summarizes the trace report with total wall clock time.

Before the fix, it took "25.038445" seconds total. Once xdg-desktop-portal backend for wlroots was installed, sway config updated, and machine restarted it became "0.028700" seconds.

That is significantly better and the same performance from what I experienced previously. Awesome! No more delays and my snappy Sway experience is back on track.

There might be other ways to solve the issue, however, I hope this might help others in answering the question, "What is happening with this process?"

If you have any additions or would like to point out errata please feel free to raise an issue on Github.

Update 2023-04-17

Turns out, per the Arch Wiki, I should have include /etc/sway/config.d/* in the ~/.config/sway/config file. This sets up some other variables as well and adds them to the dbus-daemon which also fixes issues with screen sharing in discord (browser app). My mistake came from copying my old i3 config without looking at what else should be included.