Назад | Перейти на главную страницу

Обновление ядра 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 ...». Мы выполняем их одинаково в обеих версиях ядра, поэтому не возникает проблем с запуском одного сценария более одного раза или каких-либо других процедурных различий.

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

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

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

Что вы имеете в виду под зависанием? Что происходит, чем вы выполняете 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