>>Сие сообщение значит, что ваш парсер отваливается от трубы по какой-то причине
>
>Хм, в том-то все и дело, что парсер не причем - я
>его вообще закоментировал на время в squid.sh, т.е. pipe никто не
>трогает кроме самого squid'а.
>
"It takes two to tango" - в смысле чтобы писать в трубу, обязательно должен быть тот, кто в из нее читает. Концы трубы с обеих сторон должны быть открыты ( сис. вызов open() ).
Для сквида надо, чтобы читатель был запущен раньше него и висеть на трубе на вызове read(). Иначе вылетит ошибка по сигпайпу, что имеет место в вашем случае, либо, если оба конца открыты, писатель заблокируется, пока читатель не начнет из него читать (точно не помню).>>надежнее периодически распарсивать и обнулять файл лога
>
>А если хочется чтобы это было не периодически, а постоянно?
Все зависит от того, какова допустимая задержка обновления информации в базе. Можно парсер дергать из крона хоть каждую минуту, и тогда актуальность данных в базе будет с точностью до минуты.
У меня сейчас парсер вызывается раз в час, этого, в принципе хватает.
>>Если интересно, могу поделиться своим велосипедом.
>
>Буду очень признателен если поделитесь.
ТТХ велосипеда:
парсер, вызываемый из крона, пишет в базу на постгресе, далее, посредством SQL-ных скриптов, также вызываемых из крона, информация уплотняется - трафик и время группируются по сайту. Уплотненная информация складывается в долговременный архив daily_logs, подробная информация, накопленная за сутки, убивается.
При помощи sql-ных скриптов генерируются суточные, недельные и месячные отчеты, которые складываются на web-сервер и могут посылаться почтой.
Еще можно в указать friendly_nets, трафик из которых считать не требуется.
Все это добро в виде исходника парсера, набора sql-ных, шелловских скриптов и файла кронтаба. Из доков только небольшой readme.
Куда слать?
Вариант для распечатки
Настройка Squid и других прокси серверов (Public)
(ok) on 19-Июн-07, 16:37 
