We currently listen for SIGPIPE throughout the tools. However, SIGPIPE may also be received if we write on a closed network connection. Such errors shouldn't cause the program to exit immediately or necessarily trigger cleanup behavior. If we stop explicitly listening for SIGPIPE, Go will still cause an exit if an EPIPE is received when writing to stdout or stderr. Go's behavior surrounding SIGPIPE is documents on https://golang.org/pkg/os/signal/ in the "SIGPIPE" section.

This issue is manifesting itself as an intermittent failure in the stat_discover_shard test. That test starts and stops servers while mongostat is still running and looks at how the output changes. Because we stop one of the servers it is monitoring, it received a SIGPIPE and exits.