On 08/12/2016 02:36 PM, Benjamin Marzinski wrote:
On Fri, Aug 12, 2016 at 08:57:51AM -0700, Bart Van Assche wrote:
Subject: [PATCH] libmultipath, multipathd: Rework SIGPIPE handling
The behavior we want is as follows:
* If stdout is closed then multipathd stops due to SIGPIPE.
I still don't understand why we ever what multipathd quitting with
SIGPIPE. I would much rather that the call return EPIPE and multipathd
printed a useful error message, instead of simply quitting.
Also, I don't really like putting stuff that messes with signals in the
libmpathcmd library. Some users might want their program to get get
those SIGPIPEs so they can handle them a certain way. It seems like,
since it isn't necessary to block the signal for this to work correctly,
we should not be blocking it in the library, and multipathd should
continue to make sure that it is ignoring the SIGPIPEs.
Hello Ben,
Regarding quitting upon SIGPIPE: when running a command like "multipathd
-d | head -n 1" then multipathd should quit as soon as the "head"
command has finished reading the first output line. That's why I think
that multipathd (and other executables) shouldn't ignore SIGPIPE when
writing to stdout or stderr.
Regarding libmpathcmd and SIGPIPE: the only applications that should
exit through SIGPIPE when writing to a socket are applications for which
stdout and/or stderr are redirected to a socket, e.g. daemons started by
inetd. For these daemons it is very important that these are stopped by
SIGPIPE if the other end of the socket connection is closed. However,
for the kind of socket communication that is performed by multipathd and
multipath I don't think it is useful to let socket closure trigger
SIGPIPE. This is why I think we need MSG_NOSIGNAL or the equivalent
setsockopt(sd, SOL_SOCKET, SO_NOSIGPIPE, ...) in multipath and multipathd.
Thanks,
Bart.
--
dm-devel mailing list
dm-devel@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/dm-devel
