yes: fails to trap SIGPIPE

[jfinkels]

Environment: Ubuntu 24.04, uutils main branch (git commit c250584), GNU coreutils v9.4.

Steps to reproduce:

trap '' PIPE && ./target/debug/yes | :

What happens now: uutils yes terminates successfully with no output.

What I expected to happen: GNU yes terminates successfully but displays a message on stderr:

yes: standard output: Broken pipe

Notes: this is causing a few GNU test files to be skipped, including tests/env/env-signal-handler.sh, tests/seq/seq-epipe.sh, tests/tail/pipe-f.sh, and tests/printf/printf-surprise.sh. I doubt this difference in behavior is specific to the yes program, but that's the program used to decide whether to skip the tests.

[spagdoon0411]

@sylvestre Can I try fixing this?

[cakebaker]

@spagdoon0411 sure, go ahead :)

[spagdoon0411]

This was straightforward! enable_pipe_error installs the default signal handler for SIGPIPE, killing the process before the exec function in the yes implementation gets a chance to return its Result to uumain (which means the regular error-printing route isn't taken)

I think I'll remove enable_pipe_error and pass the exec's Result back up from uumain through the regular Err arm.

Shouldn't the test cases include the broken pipe message in their "expected" buffers (see attached)? I'll plan on adding those.

Are we strict about the message itself (e.g., suffixes like os error 32)?

@cakebaker

[drinkcat]

Maybe I'm missing something, but making that simple change (remove enable_pipe_errors) doesn't work for me.

From strace, Rust decides to ignore SIGPIPE very early on in the startup process:

strace ./target/debug/yes |:
rt_sigaction(SIGPIPE, {sa_handler=SIG_IGN, sa_mask=[PIPE], sa_flags=SA_RESTORER|SA_RESTART, sa_restorer=0x7f425929aef0}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
getrandom("\x16\xc2\xbf\x17\xdd\xbf\x55\xc1", 8, GRND_NONBLOCK) = 8

and reading rust-lang/rust#97889, this looks like a limitation of Rust at the moment:

No. There is no stable workaround today. The correct behavior for Unix tools that want to behave like Unix tools is to inherit the signal disposition from the parent process. Rust throws away the original disposition, and it cannot be recovered.

[drinkcat]

For the latter part of the original report, #8353 prevents this bug from being hit in trap_sigpipe_or_skip_:

  (trap '' PIPE && timeout 10 yes |:) 2>&1 | grep 'Broken pipe' >/dev/null ||
    skip_ 'trapping SIGPIPE is not supported'

Note that, of course, both yes and timeout have this issue (so it's not enough to just use system's yes -- or timeout).