Re: bin/56110: pkg_add can fail without an error message

[Andreas Gustafsson <gson%gson.org@localhost>]

The following reply was made to PR bin/56110; it has been noted by GNATS.

From: Andreas Gustafsson <gson%gson.org@localhost>
To: Robert Elz <kre%munnari.OZ.AU@localhost>
Cc: gnats-bugs%netbsd.org@localhost
Subject: Re: bin/56110: pkg_add can fail without an error message
Date: Sat, 17 Apr 2021 15:32:38 +0300

 Robert Elz wrote:
 >    | Yet it had clearly failed, because the exit status was nonzero (141,
 >    | suggesting an EPIPE?)
 >  
 >  SIGPIPE - indicates that the process was killed by a signal (it had no chance
 >  to say anything).   Normally your shell would tell you about death by a signal,
 >  but shells tend not to make a noise about SIGPIPE exits, as they're so common.
 
 Right, SIGPIPE is what I meant :)
 
 >    | This PR is not about the package installation failing, as that may
 >    | have been caused by some network connectivity issue outside pkg_add's
 >    | control, but about pkg_add failing to print a message indicating that
 >    | it failed.
 >  
 >  The only way to deal with that would be to have pkg_add catch SIGPIPE
 >  and write an error, or ignore it (SIG_IGN I mean, not do nothing), and
 >  deal with the EPIPE error it would get instead.
 
 There's also F_SETNOSIGPIPE and MSG_NOSIGNAL.  If the SIGPIPE is
 happening inside a library such as libfetch or libssl, as I suspect is
 the case, I would argue that the right solution is to suppress or
 ignore it in the library unless it is a documented part of the library
 API.  There is already some code to do this in libfetch, but either
 it's not covering all the bases or the problem is somewhere else.
 
 > If you're able to make this happen at will,
 
 Alas, no.  Ideas for ways to do the necessary fault injection are welcome.
 -- 
 Andreas Gustafsson, gson%gson.org@localhost