Current version of sway in arch repos fail to spawn certain programs

[Zeioth]

This started to happen after the latest minor update.

$bindsym $mod+F8 foot wofi-calc

Fails to spawn wofi-calc correctly. (This is an example, happens with more programs).

The good news, is that it seems it's been fixed already on swaybg-git+sway-git+wlroots-git. Would be awesome if you can push a minor revision. Thank you.

Update: The issue also happens on swaybg-git+sway-git+wlroots-git

[bl4ckb0ne]

It would help if you can produce a stacktrace, a debug output or whatever error message wofi-cal produces.

[Zeioth]

So far I've debugged that only happens when starting sway from greetd.

This is my greetd conf file:

[terminal]
vt = "next"

[default_session]
command = "tuigreet --remember --time --issue --asterisks --cmd sway"
user = "greeter"

# Used to generate the .log
#command = "sway -d 2> ~/sway.log"
#user = "zeioth"

This is sway the log when the issue happens

[Zeioth]

A fact that got me puzzled is that the commands that fail, only fail when executed from an sway keybinding. if I run the same commands from a terminal, they run fine.

[Zeioth]

It might actually be an sway issue after all. I tested it without a greeter:

# Autostart sway when an user logs into the TTY
echo "!/bin/bash
sway" > sudo tee /etc/profile.d/sway-autostart.sh
sudo chmod +x /etc/profile.d/sway-autostart.sh

• After rebooting, and loggin into TTY, sway autostarts. I still experience the issue.

Fix found: If I just start sway from TTY manually, I don't experience the issue.

I tried several times and the results are consistent. Autostarting sway from TTY seems to be triggering the issue.

[kennylevinsen]

A common cause for this behavior would be that you are setting needed environment variables from incorrect places like .bashrc (e.g. PATH). Such place which will take effect in terminal emulators and bare ttys as they start an interactive bash session.

I'm that case, use of .profile (or better, a wrapper script around sway to not rely in .profile sourcing) is the fix.

[bl4ckb0ne]

It looks like an issue on your side regarding how you autostart sway. Without a proper backtrace from sway there isn't much we can do.

I'll close the issue, feel free to reopen it if you can provide a valid sway log.

[Zeioth]

@kennylevinsen good guess but no. The issue remains even without .zshrc/.bashrc

[FreeFull]

My guess would be something involving stdout/stderr. Maybe the file descriptors for those are closed for sway (and any programs that sway launches directly), and some programs don't like that?

[kennylevinsen]

std(in|out|err) is explicitly connected to the relevant tty by greetd.

The only differences between greetd and logging in normally in a kernek console are whether the PAM stack differs between greetd(1) and login(1) (the login manager agetty starts), and whether what you start itself differs (e.g. sway vs. interactive bash then sway).

Tip for debugging: The failing command usually says what's wrong, but it tends to be lost in sways stderr. Redirect all output to a file from your failing exec: "exec blah &>/tmp/some.log".