From mboxrd@z Thu Jan 1 00:00:00 1970 From: ludo@gnu.org (Ludovic =?UTF-8?Q?Court=C3=A8s?=) Subject: bug#29826: nondeterministic Broken pipe Date: Sun, 31 Dec 2017 11:11:15 +0100 Message-ID: <87k1x32on0.fsf@gnu.org> References: <874lohdwhb.fsf@gmail.com> <87d133lqsb.fsf@netris.org> <87608uaorx.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:33529) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eVab8-0000YP-06 for bug-guix@gnu.org; Sun, 31 Dec 2017 05:12:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eVab4-0000zW-No for bug-guix@gnu.org; Sun, 31 Dec 2017 05:12:05 -0500 Received: from debbugs.gnu.org ([208.118.235.43]:49694) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eVab4-0000zI-K5 for bug-guix@gnu.org; Sun, 31 Dec 2017 05:12:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eVab4-0005l2-Bv for bug-guix@gnu.org; Sun, 31 Dec 2017 05:12:02 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: <87608uaorx.fsf@gmail.com> (Alex Vong's message of "Mon, 25 Dec 2017 22:02:58 +0800") List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane.org@gnu.org Sender: "bug-Guix" To: Alex Vong Cc: 29826@debbugs.gnu.org Hi, 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, the >>> 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=98guix= package -A=E2=80=99, etc. In other cases, it=E2=80=99s probably an error, so it=E2=80=99s worth repor= ting. WDYT? In C such errors are usually ignored, which is nice for shell hackery but otherwise not so great. Ludo=E2=80=99.