yes command behaving unexpectedly

[bdantas]

Scripts that use yes (either busybox version or coreutils version) behave unexpectedly when running in terminal emulators (e.g., havoc) running inside labwc. Some scripts litter the screen with "Broken pipe" errors or, worse, enter an infinite loop. Here is one way to trigger an infinite loop:

echo "this is a test" >test.txt
busybox yes "password" | bcrypt test.txt

I think this is because labwc disabled SIGPIPE in version 0.6.3 and the terminal emulators are inheriting the disabled signal.

Is there a way for me to restore the normal SIGPIPE behavior in my shell? Not in the whole GUI environment--just shell scripts (including those running in a terminal emulator). I use busybox ash. Any help would be greatly appreciated.

[Consolatis]

From what I understand, signal handlers are not inherited by a execvp [0].

Additionally we remove all blocked signals when spawning a new process: https://github.com/labwc/labwc/blob/master/src/common/spawn.c#L46-L48

When you get a Broken pipe error that seems to indicate that the application in question in fact got a SIGPIPE.

busybox yes "password" | bcrypt test.txt

I don't have busybox (or bcrypt) on my system but this looks more of a bcrypt usage thing, potentially related to this quote from the man page:

Passphrases may be between 8 and 56 characters.

[0]
See man execve:

Effect on process attributes
All process attributes are preserved during an execve(), except the following:
* The dispositions of any signals that are being caught are reset to the default (signal(7))

Edit:
If you feel like testing you could comment out the signal(SIGPIPE, SIG_IGN); call in src/server.c:241, recompile labwc and see if it makes a difference. Unless you set the clipboard from a xwayland application and then read the clipboard from the wayland side and just close the fd (something like wl-paste | head -c 1) it shouldn't matter.

[bdantas]

Hi Consolatis. Wow, thank you for getting back to me so quickly!

Password meets bcrypt criteria (in fact, these same shell scripts work fine in an Xorg environment that is otherwise identical to wayland environment--identical kernel, OS, userland tools, etc). Good to know that handlers are not inherited. There is definitely something in my new wayland environment that is negatively affecting yes.

But I think I'll just avoid the usage that results in endless loop and will silence the nuisance "Broken pipe" messages with this trivial wrapper script for yes:

#!/bin/sh
exec /usr/bin/yes "$@" 2>/dev/null

Thanks again.

P.S. Migration from X to wayland has been otherwise seamless for me. I find it humorous that I can detect no breakage in the big, complicated things (web browser, email client, etc.). It's only this pinnacle of software engineering (Busybox's yes applet) that is behaving in unexpected ways! Go figure.

[Consolatis]

There is definitely something in my new wayland environment that is negatively affecting yes.

Maybe foot vs havoc would make a difference? I can't reproduce it via busybox yes "foo" | head -c 1 in either foot nor havoc though.

[clbr]

Just to clarify, later in the execve man page it says
"POSIX.1-2001 specifies that the dispositions of any signals that are
ignored or set to the default are left unchanged."

So I read it as SIG_IGN gets inherited but a signal handler would get reset.

[clbr]

This page says it more clearly:
https://lwn.net/Articles/631631/

"sets up the signal handlers for the new program; any signal handler that's not SIG_IGN gets set to the default SIG_DFL value (so any ignored signals are inherited by the new program)"

[Consolatis]

@clbr thanks for looking that up.
Hm.. interesting. That sounds like we do have to set it manually to SIG_DFL again before doing the exec.

@bdantas if you have the chance, trying to comment out the line mentioned in the edit of #1209 (comment) would confirm that this is actually the issue here. Alternatively you could try

• src/common/spawn.c: Restore SIGPIPE default handler before exec #1210

[bdantas]

@clbr Thanks for pitching in and for confirming what I suspected based on observed behavior.

@Consolatis: I recompiled labwc with this
#1210
and yes now behaves as expected. I will re-package labwc for TCL x86_64 with this fix. Many thanks!

[Consolatis]

Should be fixed on latest master.

Thanks @bdantas for reporting + testing and thanks @clbr for stepping in and correcting me.