I'm not sure if the @rust-lang/libs team is the right team for this; suggestions welcome if another team would be the right owner for "behavior of Rust at application start-up".

If we stop ignoring SIGPIPE by default, we will break back compat for every socket server written in Rust, right?

Perhaps we should have a build-time option for this to make it easy to disable/enable in an application?

Why this and e.g. not an attribute on fn main() {? (As a general rule, I think having program semantics defined as much as possible by the source code is preferable to flags since it makes things more standalone.)

@sfackler Right now, we have inconsistent behavior, where your socket server will also break if you ever write main() in any language other than Rust, and turn your code into a library. That flies in the face of one of Rust's greatest strengths: "we don't have a runtime". I discovered this when looking over the pre-main startup code.

At the very least, we need to document that we ignore SIGPIPE, and we need to provide an easy way to disable this behavior. I'd also fully expect that any change to the default itself would require a sizable transition period (or even an edition).

@Centril Good point! An attribute within the source code (on main or the top-level module) does indeed seem preferable, rather than a build-time option.

I agree that we should do something about this. I don't think we can change the current default behavior because of backcompat concerns, as @sfackler mentioned, but the current status quo is that nominal command line applications start out of the gate as broken, and it's a fairly subtle issue to fix. Firstly, if you're using println! and have enough output to exceed stdout's default buffer size, then it's likely that running, for example, command | head -n1 will result in a panic. Secondly, if you're using writeln!(...)? instead, and are setting an error code when writeln!(...) fails, then it's likely that command | head -n1 will stop with an unexpected exit code.

For example, normally a process will exit with a 141 exit code upon receipt of a pipe error:

$ seq 1 10000 | head -n1
1
$ echo ${pipestatus[1]}
141

So to fix this, you firstly need to know enough to use writeln!(...), and then you either need to assume all errors produced by writeln!(...) are broken pipe errors (and emit the correct exit code), or explicitly check errors for io::ErrorKind::BrokenPipe and respond accordingly. The former is, strictly speaking, incorrect, even though it's likely the only error you'll encounter when writing to stdout is a broken pipe error (but the code using write! may not know that it is writing to stdout). The latter works, but it's tedious, and even I get it wrong:

$ rg . rust/ | head -n1
rust/bstr/rustfmt.toml:disable_all_formatting = true
$ echo ${pipestatus[1]}
0

This, presumably, should be 141. But at least it doesn't panic.

So yeah, on the one hand, ignoring SIGPIPE by default means pure Rust networked applications probably have the right behavior by default, but not ignoring SIGPIPE by default means command line applications probably have the wrong behavior by default. Both of these groups seem fairly sizable to me.

I don't mind the idea of some incantation one can put in the source code to fix this. An alternative might be to just provide a function in std, if it's possible, that un-ignores SIGPIPE and is intended to run at the beginning of main. If that's workable, then that might be preferrable since it adds fewer directives to the language itself. The other issue here is documentation and discoverability. i.e., How can we help folks writing CLI tools discover, in the first place, that they need to un-ignore SIGPIPE?

(Although, I guess adding a function to std and requiring users to call it doesn't fix @joshtriplett's case, where Rust is a library. Am I understanding that right?)

I personally agree with @sfackler that I don't think we can really change any defaults due to backwards-compatibility reasons. AFAIK this really only affects one thing which is unix-y CLI applications. Any portable CLI application to Windows cannot rely on the existence of SIGPIPE and almost all non-CLI applications I imagine want to receive errors instead of SIGPIPE to handle. That feels, to me, niche enough that we made the defaults the right way and there should be documentation/crates for authors writing unix-y CLI applications (aka ripgrep and such).

@alexcrichton I agree that we have to handle backwards-compatibility, but that wouldn't stop us from having a top-level attribute to opt-out of it.

If the proposal ends up boiling down to adding a new top-level attribute to opt-out, then I think a blocker in my mind for the proposal would be to justify why a change to the compiler/standard library is necessary when otherwise a crate on crates.io would only require two lines to add to a project (e.g. a dependency directive in Cargo.toml and a one-liner in src/main.rs to enable)

@alexcrichton Because there's a difference between "do some setup to ignore SIGPIPE, then un-ignore it" and "never ignore SIGPIPE in the first place". Because people want to build smaller, faster executables. Because libraries and applications shouldn't have subtle differences in behavior, especially undocumented differences. Because you can do this in C and Rust makes it difficult. Because not every project should need to have a dependency to do this. Because it's a pain to add a platform-specific dependency and a platform-specific one-liner for an application that could otherwise be portable, and #![no_ignore_sigpipe] would be easier. Because it should be possible to write Rust code that doesn't have any startup code at all, and with some care we could potentially eliminate all of the current startup code in the future.

Er sorry that sort of feels like a particularly antagonistic reponse to me? Many of your "Because ..." can be pretty trivially fixed (the crate doesn't have to be platform specific, difficulty seems like it's a function of the crate, etc) and seem like they're maybe blowing the problem out of proportion (we're not slowing down executables or bloating them by adding an extra syscall at the beginning)?

I think one of the main points you're bringing up is the difference in library/binary behavior today, but from what @sfackler mentioned above and I agree we unfortunately can't change the binary behavior and library authors largely just need to be aware of this if they run into it (which thankfully isn't all the time). We can of course also have crates to smooth this over one way or another.

My point (which I don't think you really addressed?) was that I don't understand why a compiler solution is needed. It seems that a suitable crate can be added to crates.io to solve almost all of these issues.

My point (which I don't think you really addressed?) was that I don't understand why a compiler solution is needed. It seems that a suitable crate can be added to crates.io to solve almost all of these issues.

It's possible to make a crate that causes start to never register a sigpipe handler at all? I thought that was pretty baked in?

If this can be reasonably supported as a library function then that seems like the best solution since it is low cost. At any rate if people absolutely don't want to take on that dependency then libstd is still lower cost than a built in attribute. All in all I think @alexcrichton makes fine points.

@alexcrichton My apologies, I certainly didn't intend to come across as antagonistic.

My most specific point is that a library crate can only undo what std does, it can't stop std from doing it in the first place. I'd like a solution that provides more control over what Rust's startup code is doing in the first place.

(Also, as one more reason, every unnecessary syscall also represents an additional syscall needed in seccomp filters to lock down a program.)

@OvermindDL1

It's possible to make a crate that causes start to never register a sigpipe handler at all? I thought that was pretty baked in?

Exactly. That's the main reason I'm asking after having built-in support.

Exactly. That's the main reason I'm asking after having built-in support.

I thought as much, it really should be in the compiler then. An attribute on main seems sufficient, or even a compiler flag (exposed via something in the Cargo.toml file perhaps as well?).

This seems like a problem that could be fixed with the next edition? That would justify the use of an attribute to disable/enable this feature, in that upgrading binary crates to the new edition would need to add the attribute to re-enable this feature.

Changing any signal disposition by default in the startup code is inherently broken, because dispositions are inherited across fork/exec. The same goes for signal masking. IMO this behavior should just be removed.

If you really really don't want SIGPIPE to happen, without applications having to take their own measures to stop it, there is a right way that does not clobber any state. For each write or equivalent (note: send and sendto can just use sendmsg as their backend with MSG_NOSIGNAL flag), do the following:

1. Block SIGPIPE.
2. Perform the write.
3. If it failed with EPIPE, call sigwaitinfoto consume theSIGPIPE` while it's still blocked.
4. Restore the old mask.

This procedure is entirely portable and thread-safe, because signal masks are thread-local and SIGPIPE is generated synchronously for the thread, not for the process.

an alternate solution:
println! calls std::process::exit(141) instead of panic!() if it fails on EPIPE

that way, both servers and cli tools work by default

The issue of igoring SIGPIPE is related to, but separate from, the issue of what println! does on write failure. Changing signal dispositions behind the application's back in a way it has no way to fix up before exec'ing something else (AFAICT the original disposition is lost) is a much bigger problem than what println! does, since applications can just refrain from using println!.

With that said, I agree std::process::exit(141) would be less bad than panic!(). The latter should be for programming errors, not for completely valid runtime conditions.

This came up in a StackOverflow question, and my advice was basically, "either don't use println! in non-toy programs, or use this unsafe FFI binding via libc to re-enable the default behavior for handling PIPE signals."

println! calls std::process::exit(141) instead of panic!() if it fails on EPIPE

If you have multiple threads, this will abort the whole process instead of only panicking the current thread.

@jyn514 yes. That's exactly what you want in most CLI programs.

@BurntSushi Programs using println! are not necessarily CLI programs, though. They may, for instance, be servers that use stdout/stderr for logging.

Another reason not to use std::process::exit(141) is that it is not
the same as being killed by a SIGPIPE. Standard shells will report
“termination by signal n” as return value n 128, but this is a
property of the shell, not the system (e.g., man bash).

You can distinguish the two cases from the output of waitpid(2):

use std::os::unix::process::ExitStatusExt;
use std::process::{Command, Stdio};

/// Runs POSIX shell command `shell` in a context with its stdout closed (probably; technically
/// racy), and reports on the exit status's code or signal.
fn check(shell: &str) -> std::io::Result<()> {
    let mut child = Command::new("sh")
        .args(&["-c", "sleep 0.1; exec sh -c \"$@\"", ":", shell])
        .stdout(Stdio::piped())
        .spawn()?;
    drop(child.stdout.take().unwrap());
    let status = child.wait()?;
    println!(
        "{:?} exited with code {:?}; signal: {:?}",
        shell,
        status.code(),
        status.signal(),
    );
    Ok(())
}

fn main() -> std::io::Result<()> {
    check("exit 141")?;
    check("echo sigpipe")?;
    check("kill -13 $$")?;
    Ok(())
}

This prints:

"exit 141" exited with code Some(141); signal: None
"echo sigpipe" exited with code None; signal: Some(13)
"kill -13 $$" exited with code None; signal: Some(13)

We can see that a bare exit terminates with a code and no signal,
whereas being killed terminates with a signal and no code.

Further reading: “Proper handling of SIGINT/SIGQUIT” describes how
this can be important. Choice quote: “You cannot "fake" the proper exit
status by an exit(3) with a special numeric value, even if you look up
the numeric value for your system” (emphasis in original).

If you really really don't want SIGPIPE to happen, without applications having to take their own measures to stop it, there is a right way that does not clobber any state. For each write or equivalent (note: send and sendto can just use sendmsg as their backend with MSG_NOSIGNAL flag), do the following:

1. Block `SIGPIPE`.
2. Perform the `write`.
3. If it failed with `EPIPE, call `sigwaitinfo`to consume the`SIGPIPE` while it's still blocked.
4. Restore the old mask.

This procedure is entirely portable and thread-safe, because signal masks are thread-local and SIGPIPE is generated synchronously for the thread, not for the process.

This approach is interesting, but the issue with it is that you must now apply this to every single thing that calls write() and might be hitting a pipe, even File due to named fifos. And that wouldn't just be std code but also libraries that roll their own IO via libc calls. Which also means now everything that does IO pays increased syscall costs (which have gone up due to CPU vulnerability mitigations).
All that just to keep some global state intact that maybe ought be inherited by child processes.

An equivalent to MSG_NOSIGNAL for write() would be much more palatable but that does not appear to exist.

Another problem with this is it is expensive; introducing multiple system calls for every call to write() -- which often occur in a tight loop -- is quite undesirable.