Обновление ядра Linux сломало именованные каналы

Обновление ядра Linux сломало именованные каналы

Мы заметили изменение в именованных каналах после обновления ядра Linux. Использование скриптов изhttp://www.linuxjournal.com/content/using-named-pipes-fifos-bash, нам удалось воспроизвести проблему. Скрипты работают на

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

но держись

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

Кажется, есть разница в том, как работают именованные каналы. Это намеренно или нет?

Мы сохранили два скрипта как 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"

и 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

Есть ли решение?

РЕДАКТИРОВАТЬ:

Мы запускаем каждый скрипт в его собственном терминале. Они зависают в том смысле, что скрипт-писатель никогда не существует, а скрипт-читатель никогда не показывает нормальный вывод "Hello from...". Мы выполняем их одинаково в обеих версиях ядра, поэтому это не проблема запуска одного скрипта более одного раза или каких-либо других процедурных различий.

решение1

У меня недостаточно репутации, чтобы написать комментарий, поэтому пишу в качестве ответа.

Что вы подразумеваете под зависанием? Что происходит, когда вы выполняете pipe_reader.shи pipe_writer.shв другом терминале?

Кроме того, после выполнения обоих скриптов, что делает команда:

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

показывать?

Может быть, вы запустили несколько скриптов .pipe_reader, так что только первый из них получает вывод pipe_writer? Убедитесь, что

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

возвращает 1

решение2

Насколько я понимаю, 3.13.0-55 и 3.13.0-65 ​​— это одно и то же ядро ​​(3.13) с некоторыми исправлениями/патчами от поставщика дистрибутивов. Маловероятно, что функциональность конвейера изменится с этим обновлением. Я считаю, что нарушение такой функциональности будет нежелательно для разработчиков ядра.

Происходит что-то еще.

Связанный контент