[dm-devel] [PATCH V6 1/3] multipath-tools: New way to limit the IPC command length.

[Bart Van Assche]

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.