I think this proposal is a bad idea. Any Go program whose output might go into a pipe will now need a signal handler. The flag in 11389 is panicking on error, not EPIPE per se.

This proposal would make Go programs act like C programs by default: writing to a closed pipe would cause the program to exit due to a SIGPIPE signal. To avoid that, a Go program would have to call signal.Ignore(syscall.SIGPIPE), which I agree is not ideal because it's Unix-specific.

I also agree that this might be a bad default for Go. In that case, I think we need a simple way for Go programs to say that they should exit when writing to a closed pipe, to avoid the contortions required to check for EPIPE. It would be appropriate for any Go program that acts as a command line client to make that call. Right now, a Go program can do it by calling syscall.Reset(syscall.SIGPIPE), and perhaps the go tool should do that at least for the help command. But, again, it's Unix-specific.

Maybe we need something like runtime.ExitOnBrokenPipe(bool).

FWIW I disagree that Go programs should act like C programs by default, especially because you get SIGPIPE for writes to closed network connections too. If we could somehow make SIGPIPE only come in for writes to standard output or standard error, maybe that would be okay.

I think the real problem is that the template package does not distinguish template errors from write errors in any useful way.

There may be a problem with the template package, but I think there is also a different problem here. If I have a command line tool that generates output, I want that tool to receive a SIGPIPE signal, and exit because of it, if it is writing to a closed pipe. Having that only happen after 10 writes fail is arbitrary and fails if I do fewer than 10 writes.

one might also have a long-running go-program which is supervised by systemd. and it is "logging" to stdout/stderr. and systemd will write that log to journald. and someone is restarting journald (because that someone is changing, lets say, the compression of the .journal files). and that someone is running systemd-218 or below (so systemd won't save the given filedescriptors such as implemented in systemd-219+).

upon journald-restart the program will get SIGPIPE and and it is very reasonable to shut down the program as well (since someone removed the "logging" infrastructure underneath).

See #11898

Proposal after talking to Russ:

1. Drop the EPIPE counter.
2. By default, if we get an EPIPE on os.Stdout or os.Stderr, change the SIGPIPE handler to SIG_DFL and raise SIGPIPE (that is, do what we currently do after getting 10 EPIPE errors, but do it immediately.)
3. On other descriptors, simply return EPIPE to the caller of Write (as we do today, up to 10 EPIPE errors).
4. If the program calls os/signal.Notify(syscall.SIGPIPE) or os/signal.Ignore(syscall.SIGPIPE), then do not handle EPIPE specially on os.Stdout/os.Stderr.

With these rules:

1. A command line program writing to a pipe on Stdout or Stderr will do the right thing by default.
2. A server writing to a closed socket will do the right thing by default (i.e., get an error but not crash).
3. The program may look for an EPIPE error as it can today.
4. The program may call os/signal.Notify to explicitly handle SIGPIPE in some other way.

Of course, this should all be documented somewhere.

"Proposal" accepted.

Sorry to be pedantic, but what exactly does it mean to get an EPIPE "on os.Stdout or os.Stderr"? E.g.,

1. If I re-set os.Stdout = os.NewFile(1, "/dev/stdout") and then get an EPIPE writing to os.Stdout, is SIGPIPE raised?
2. What if I set os.Stdout to an *os.File value created some other way and get EPIPE?
3. What if I do stdout := os.Stdout; os.Stdout = nil; stdout.Write(...) and get an EPIPE?
4. What if I just do os.NewFile(1, "/dev/stdout").Write(...) and get an EPIPE?

I'm thinking only case 3 should raise SIGPIPE (i.e., the behavior is tied to the *os.File values used to initialize os.Stdout and os.Stderr).

I was thinking it meant fd 1 or fd 2.

That seems justifiable to me too.

CL https://golang.org/cl/18151 mentions this issue.

CL https://golang.org/cl/18226 mentions this issue.