#822605 bugs.debian.org: Named pipe (mkfifo) input/output seriously broken, reproducible

Package:
bash
Source:
bash
Description:
GNU Bourne Again SHell
Submitter:
Marco Ippolito
Date:
2024-03-21 20:45:08 UTC
Severity:
important
Tags:
#822605#5
Date:
2016-04-25 15:13:55 UTC
From:
To:
Dear Maintainer,

   this has a major effect on the software I use, it seems to be fundamental to
   all named pipe I/O.

   * What led up to the situation?

   - Most software I use reading/writing to a named pipe becomes unreliable!

   * What exactly did you do (or not do) that was effective (or
     ineffective)?

   - I tried the code that reproduces the problem below elsewhere (e.g. Debian
     Wheezy, other distributions, ...) and it works fine. Not on Stretch.

   * What was the outcome of this action?

   - Seems broken only on Stretch, of the systems I could test. Feel free to
     investigate elsewhere too.

   * What outcome did you expect instead?

   - Setting up and running two sides of a named pipe producer/consumer is broken:

     Side "Producer": (from a Bash instance)

     rm /tmp/f; mkfifo /tmp/f; n_crashes=0; while true; do echo \
     n_crashes=$n_crashes; (i=0; while true; do echo $((i++)) > /tmp/f; done); \
     ((n_crashes++)); done

     Side "Consumer": (again, a Bash instance; a separate Bash instance)

     while true; do echo $(< /tmp/f); done
#822605#10
Date:
2016-04-25 15:24:15 UTC
From:
To:
reassign 822605 linux
tag 822605 moreinfo
found linux/4.5.0-1
thanks

You've reported a bug against bugs.debian.org, the psuedopackage which
is responsible for the bug tracking system, not general bugs in Debian.
For future reference, the correct package for this bug (I think) is
probably the linux kernel, which handles named fifos.

How exactly does it become unreliable?

I'm guessing you're using linux 4.5.0-1? Does 4.5.1 show the same
behavior? [4.5.1-1 is what is currently in unstable and testing.]

Broken in what way?
#822605#19
Date:
2016-04-25 15:31:33 UTC
From:
To:
@Don Armstrong: how does it behave for you, if you run both sides of
that Producer/Consumer loop from different Bash shells, communicating
through the /tmp/f named pipe? Specifically, does n_crashes increase for
you?

Sorry about the incorrect bug routing. Oversight accepting a default in
`reportbug'.
#822605#26
Date:
2016-04-28 13:00:41 UTC
From:
To:
These scripts have a race condition, such that this can happen:

Producer       Consumer
--------       --------
open...                    (producer blocks)
               open        (producer unblocked)
               read
write
close
open
               close
write

And fifo(7) says that this write() will result in a SIGPIPE.  So I
don't think there is a kernel bug here.  But it is incorrect that
SIGPIPE terminates the subshell.

When bash runs a builtin command without forking, it should install a
SIGPIPE handler that will cause that signal to abort the command but
not terminate the shell.

Ben.
#822605#35
Date:
2024-03-21 15:42:24 UTC
From:
To:
Bash 5.2.21 still exhibits this issue, the subshell terminates once a
SIGPIPE is received:

(shell1)$ rm -f /tmp/f && mkfifo /tmp/f && (i=0; while true; do echo
$((i=i+1)) > /tmp/f; done); echo "terminated with exit status $?"

(shell2)$ while true; do echo $(< /tmp/f); done

The command in shell1 will output "terminated with exit status 141".

For the record, dash 0.5.12 has the same behavior.

Regards,