Linux kernel upgrade broke named pipes

Question

We noticed a change with named pipes after a linux kernel upgrade. Using the scripts from http://www.linuxjournal.com/content/using-named-pipes-fifos-bash, we were able to replicate the issue. The scripts work on

Linux TEST05 3.13.0-55-generic #94-Ubuntu SMP Thu Jun 18 00:27:10 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

but hang on

Linux TEST01 3.13.0-65-generic #106-Ubuntu SMP Fri Oct 2 22:08:27 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

There seems to be a difference in how named pipes work. Is that intentional or not?

We captured the two scripts as pipe_reader.sh:

#!/bin/bash

pipe=/tmp/testpipe

trap "rm -f $pipe" EXIT

if [[ ! -p $pipe ]]; then
    mkfifo $pipe
fi

while true
do
    if read line <$pipe; then
        if [[ "$line" == 'quit' ]]; then
            break
        fi
        echo $line
    fi
done

echo "Reader exiting"

and pipe_writer.sh:

#!/bin/bash

pipe=/tmp/testpipe

if [[ ! -p $pipe ]]; then
    echo "Reader not running"
    exit 1
fi


if [[ "$1" ]]; then
    echo "$1" >$pipe
else
    echo "Hello from $$" >$pipe
fi

Is there a fix?

EDIT:

We're running each script in its own terminal. They hang in the sense that the writer script never exists, and the reader script never shows the normal "Hello from..." output. We're executing them in an identical fashion under both kernel versions, so it's not an issue of running one script more than once, or any other procedural differences.

Unfortunately, we've downgraded the host where I could reproduce the problem. When I set up another box identically (using ansible scripts) the kernel version that didn't work now works fine. Perhaps we got a corrupt version of the kernel, not sure, but now I have no way to reproduce the problem. :( — Don Branson, Oct 06 '15 at 17:12
I just tested on my machine with same kernel and the script works fine (well, I just echo'd manually but the named pipe functionality is fine). Since it's now working for you too, I guess it was just a glitch in the matrix. Or maybe /tmp was full or had bad permissions on your last machine. — seumasmac, Oct 06 '15 at 23:47

score 0 · Answer 1 · answered Oct 06 '15 at 16:15

0

I have not enough of reputation to write comment, so writing as an answer.

What do you mean by hang? What happens than you execute pipe_reader.sh and pipe_writer.sh in other terminal?

Also, after executing both scripts, what does command:

ls -al /proc/$(pgrep pipe_reader.sh)/fd

show?

Maybe you have ran several .pipe_reader scripts, so only the first one receive the pipe_writer output? Make sure that

ps aux | grep pipe_reader | grep -v grep | wc -l

returns 1

answered Oct 06 '15 at 16:15

gilbertasm

85
2
13

Question updated. – Don Branson Oct 06 '15 at 16:22
please add output of `strace ./pipe_reader` and `strace ./pipe_writer.sh` – gilbertasm Oct 06 '15 at 16:27

score 0 · Answer 2 · answered Oct 06 '15 at 23:39

From what I understand 3.13.0-55 and 3.13.0-65 are both the same kernel (3.13) with some fixes/patches by the distribution provider. It is unlikely that the pipe functionality would be altered with this upgrade. I believe that breaking such functionality would be frowned upon by kernel developers.

There's something else going on.

Linux kernel upgrade broke named pipes

2 Answers2