Remove SIGPIPE handler (#2558)

## Proposed Changes

Remove the SIGPIPE handler added in #2486.

We saw some of the testnet nodes running under `systemd` being stopped due to `journald` restarts. The systemd docs state:

> If systemd-journald.service is stopped, the stream connections associated with all services are terminated. Further writes to those streams by the service will result in EPIPE errors. In order to react gracefully in this case it is recommended that programs logging to standard output/error ignore such errors. If the SIGPIPE UNIX signal handler is not blocked or turned off, such write attempts will also result in such process signals being generated, see signal(7).

From https://www.freedesktop.org/software/systemd/man/systemd-journald.service.html

## Additional Info

It turned out that the issue described in #2114 was due to `tee`'s behaviour rather than Lighthouse's, so the SIGPIPE handler isn't required for any current use case. An alternative to disabling it all together would be to exit with a non-zero code so that systemd knows to restart the process, but it seems more desirable to tolerate journald glitches than to restart frequently.
This commit is contained in:
Michael Sproul 2021-09-03 04:26:06 +00:00
parent ac274221c5
commit d9910f96c5

View File

@ -391,15 +391,6 @@ impl<E: EthSpec> Environment<E> {
Err(e) => error!(self.log, "Could not register SIGHUP handler"; "error" => e),
}
// setup for handling a SIGPIPE
match signal(SignalKind::pipe()) {
Ok(pipe_stream) => {
let pipe = SignalFuture::new(pipe_stream, "Received SIGPIPE");
handles.push(pipe);
}
Err(e) => error!(self.log, "Could not register SIGPIPE handler"; "error" => e),
}
future::select(inner_shutdown, future::select_all(handles.into_iter())).await
}) {
future::Either::Left((Ok(reason), _)) => {