[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#29826: nondeterministic Broken pipe

From: Alex Vong
Subject: bug#29826: nondeterministic Broken pipe
Date: Tue, 02 Jan 2018 20:07:41 +0800
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.3 (gnu/linux)


address@hidden (Ludovic Courtès) writes:

> Hi,
> Alex Vong <address@hidden> skribis:
>> Mark H Weaver <address@hidden> writes:
>>> Alex Vong <address@hidden> 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 <http://bugs.gnu.org/27017>. 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 ‘guix package --search’, ‘guix package -A’, etc.
> In other cases, it’s probably an error, so it’s worth reporting.
> In C such errors are usually ignored, which is nice for shell hackery
> but otherwise not so great.
> Ludo’.

Do you mean there are use-cases where the EPIPE signal really means
there is an error? What I think is that the 'guix' command is meant to
be used in a shell script, so it should work nice with other shell tools
in a pipe, including head & tail. But maybe it will cause other problems
if we always ignore EPIPE, I don't know... 

Attachment: signature.asc
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]