From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 02 14:04:48 2018 Received: (at 29826) by debbugs.gnu.org; 2 Jan 2018 19:04:48 +0000 Received: from localhost ([127.0.0.1]:33438 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eWRrk-0004rR-9V for submit@debbugs.gnu.org; Tue, 02 Jan 2018 14:04:48 -0500 Received: from world.peace.net ([50.252.239.5]:44970) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eWRri-0004rF-V5 for 29826@debbugs.gnu.org; Tue, 02 Jan 2018 14:04:47 -0500 Received: from pool-72-93-27-221.bstnma.east.verizon.net ([72.93.27.221] helo=jojen) by world.peace.net with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1eWRrc-0005Fo-Ix; Tue, 02 Jan 2018 14:04:40 -0500 From: Mark H Weaver To: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Subject: Re: bug#29826: nondeterministic Broken pipe References: <874lohdwhb.fsf@gmail.com> <87d133lqsb.fsf@netris.org> <87608uaorx.fsf@gmail.com> <87k1x32on0.fsf@gnu.org> Date: Tue, 02 Jan 2018 14:04:16 -0500 In-Reply-To: <87k1x32on0.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Sun, 31 Dec 2017 11:11:15 +0100") Message-ID: <87inckxetr.fsf@netris.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 29826 Cc: Alex Vong , 29826@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.0 (/) Hi, ludo@gnu.org (Ludovic Court=C3=A8s) writes: > Alex Vong skribis: > >> Mark H Weaver writes: >> >>> Alex Vong writes: >>> >>>> I get the following error when running ``guix --version | head -n 1''.= I >>>> can get similar after replacing ``--version'' with ``--help''. Also, t= he >>>> error is nondeterministic. Any idea? >>> >>> Attempts to write to a pipe that has already been closed on the other >>> end results in EPIPE. From the write(2) man page: >>> >>> EPIPE fd is connected to a pipe or socket whose reading end is closed. >>> When this happens the writing process will also receive a >>> SIGPIPE signal. (Thus, the write return value is seen only if >>> the program catches, blocks or ignores this signal.) >>> >>> In this case, there's a race condition. The result depends on whether >>> "head -n 1" closes its end of the pipe before or after "guix --version" >>> is finished writing all of its output. If "head -n 1" closes the pipe >>> first, then "guix --version" will receive EPIPE while attempting to >>> write to it. >>> >>> What normally happens is that the sending process receives SIGPIPE, >>> which simply causes it to exit prematurely without ever receiving this >>> error. However, since Guix arranges to ignore SIGPIPE in >>> 'initialize-guix' in guix/ui.scm, we receive EPIPE. >>> >>> That's what's happening here. I'll need to think on how best to fix it. >>> >>> Regards, >>> Mark >> >> Nice explaination as always! I forget to mention that I reported a bug >> of similar flavour before . I agree that >> thought is needed to fix all instances of this type of bug. > > Not sure! We specifically ignore EPIPE in cases where it matters, such > as for the output of =E2=80=98guix package --search=E2=80=99, =E2=80=98gu= ix package -A=E2=80=99, etc. > In other cases, it=E2=80=99s probably an error, so it=E2=80=99s worth rep= orting. > > WDYT? I see from the comment in (guix ui) where SIGPIPE is ignored, the rationale: ;; Ignore SIGPIPE. If the daemon closes the connection, we prefer to be ;; notified via an EPIPE later. (sigaction SIGPIPE SIG_IGN) Instead of unconditionally ignoring SIGPIPE here in (initialize-guix), it might be better to ignore SIGPIPE only if we open a connection to the daemon with the intent of mutating the store, and perhaps in some other cases where we're mutating information on disk (e.g. switching generations). In those cases, we have a job to do that should ideally be completed regardless of whether anyone is still listening to our STDOUT. However, in many other cases, we don't mutate anything on disk, and our *only* job is printing information to the user, e.g. when showing version/usage information, the list of available packages, the list of generations, etc. In those cases, I think it would be better to let SIGPIPE kill us, because there is no reason to keep the 'guix' process alive if its output is going nowhere. These are also the cases where it's most useful to pipe 'guix' output into other commands. So, I think we should consider removing (sigaction SIGPIPE SIG_IGN) from (initialize-guix), and instead putting it in various other selected places. What do you think? Mark