[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) |
Hello,
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.
>
> WDYT?
>
> 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...
signature.asc
Description: PGP signature
- bug#29826: nondeterministic Broken pipe,
Alex Vong <=