BASH: Проблемы с Fifo - кажется избирательным в отношении ввода
Это было бы сделано в Вашем httpd.conf файле как виртуальный хост. Это посмотрело бы что-то как:
<VirtualHost thisdomain.com:8880>
DocumentRoot /www/docs/svn/myapp
ServerName thisdomain.com
</VirtualHost
Удостоверьтесь, что апач является lisening для правильного порта. Найдите, где, говорит listen 80 и включайте listen 8880
По какой-то причине он начал разборчиво выбирать, кто может писать (или, по крайней мере, казалось, кто может писать) в трубку. Я не видел ошибок, но я пытался отправить текст в канал, и на стороне службы ничего не происходило.
Если ваша программа раньше работала, а та же программа не работает, проверьте, не изменилась ли ее среда.
Симптомы соответствуют наличию нескольких читателей на трубке и наблюдению только за одним из читателей. Когда несколько процессов читают из канала, данные могут поступать в любой из процессов.
Вы используете именованный канал с фиксированным именем. Скорее всего, у вас где-то есть случайный экземпляр читательской части вашей программы.
Вы можете проверить, у каких процессов открыт именованный канал, с помощью lsof :
lsof .../path/fifoIn
Если в канале нет записи, могут быть считыватели, которые заблокированы при открытии call - открытие именованного канала блокирует, пока не появится писатель. lsof не будет сообщать об этом, поскольку канал еще не открыт. Я не знаю, как найти процессы, которые заблокированы при вызове open . Вы можете вызвать возврат вызова open во всех процессах, открыв его для записи:
sleep 99999999 >.../path/fifoIn &
lsof .../path/fifoIn
Имейте в виду, что открытые файлы наследуются подпроцессами. Если ваша программа запускает другие программы в фоновом режиме при открытом канале, канал для этих программ может оставаться открытым для чтения. Вы можете захотеть закрыть канал:
while … do
subprocess_that_does_not_need_the_pipe </dev/null
done <.../path/fifoIn
или
while … do
subprocess_that_does_not_need_the_pipe 0<&3
done 3<&0 <.../path/fifoIn