Приветствую. Пытаюсь освоить pipes в баше.
Дело такое: создаю named-пайп, запускаю демон, который пишет в этот пайп периодически, когда ему вздумается (включая stderr):
mkfifo npipe
some_daemon 1> npipe 2>&1
А так же создаю фоновый процесс, который читает пайпы и выводит на экран для теста построчно:
bg_proc () {
while read LINE; do
echo "---$LINE---"
done < npipe
}
bg_proc &
Всё вроде бы ничего, пайпы пишутся, выводятся в духе:
---message from daemon #1---
---message from daemon #2---
---message from daemon #3---
Но иногда, видимо когда демон отправляет сообщения слишком быстро — возникает конфликт, и получается что-то в духе:
---message fmessage daemon #2---
После чего никакие дальнейшие сообщения от демона не доходят. Что я упустил, и как решать конфликт? Заранее благодарю!
С coproc никогда раньше дел не имел, гуглил-гуглил. Запустил процесс через
coproc some_daemon
он как положено вернул свой pid, но на команды cosend и coreceive баш ругается: команда мол не найдена (Fedora 19), манов у меня в системе по команде тоже нет, смотрел тут: http://www.unix.com/man-page/all/1f/coproc/
Да, но ведь при переполнении этих 4-ёх КиБ оно просто ждёт пока «чтец» не начнёт читать данные, чтобы освободить это место, а как видно по моему примеру — попытка чтения у меня непрерывная, цикличная. Я тестировал и так:
bg_proc () {
while read LINE; do
echo "---$LINE---"
done < npipe
echo "THE END"
}
bg_proc &
И “THE END” я не вижу, покуда не оборву выполнение чрез Ctrl+C, а точнее — покуда не ляжет демон, который пишет свой «выхлоп» в пайп. То-есть ожидание данных на чтение имеется.
Плюс FIFO позиционируется как “First In — First Out”, а тут получается одна из записей вклинивается и всё ломается, часть от старой записи, часть от другой и дальше процесс остановлен, непонятно чем, а точнее сказать — заморожен, потому что чтение продолжается, просто провисает в ожидании.
Мне пока непонятен камень преткновения с многотридностью демона, когда разные триды пишут в stdout, если бы были конфликты, про которые я описал (когда одно влезает поверх предыдущего), то по моим логическим представлениям, то же самое бы творилось и с обычным, не перехваченным выводом в терминал, но этого не происходит. Единственное предположение, на этот счёт, что переполняются тех самых 4кб, но демон не впадает в ожидание доступности записи, а продолжает пытаться слать на stdout данные, игнорируя невозможность писать, хотя это и не совсем в общую картину клеится, но хоть как-то объясняет суть проблемы мне, быть может версия хотябы приблизительно истинная.
