URL: https://www.opennet.me/cgi-bin/openforum/vsluhboard.cgi
Форум: vsluhforumID12
Нить номер: 4953
[ Назад ]
Исходное сообщение
"Проблема с access.log в pipe-канале (fifo)"
Отправлено Turbid , 19-Июн-07 16:37 
Здраствуйте.

Прикручиваю к проксику статистику как это описано тут: http://www.uvsw.narod.ru/project/squid2mysql.html

Проблемма стала такая - проксик отваливается при обращении к логу, в /var/log/messages пишется следующее:

Jun 19 10:31:22 su kernel: pid 995 (squid), uid 100: exited on signal 6
Jun 19 10:31:22 su (squid): logfileWrite: /usr/local/squid/logs/access.log: (32) Broken pipe
Jun 19 10:31:22 su squid[929]: Squid Parent: child process 995 exited due to signal 6
Jun 19 10:31:25 su squid[929]: Squid Parent: child process 1009 started

Если pipe заменяю на обычный лог, то все работает.

Очень надеюсь на помощь.

Содержание
Сообщения в этом обсуждении
"Проблема с access.log в pipe-канале (fifo)"
Отправлено Newcomer , 19-Июн-07 17:23 
>Здраствуйте.
>
>Прикручиваю к проксику статистику как это описано тут: http://www.uvsw.narod.ru/project/squid2mysql.html
>
>Проблемма стала такая - проксик отваливается при обращении к логу, в /var/log/messages
>пишется следующее:
>
>Jun 19 10:31:22 su kernel: pid 995 (squid), uid 100: exited on
>signal 6
>Jun 19 10:31:22 su (squid): logfileWrite: /usr/local/squid/logs/access.log: (32) Broken pipe
>Jun 19 10:31:22 su squid[929]: Squid Parent: child process 995 exited due
>to signal 6
>Jun 19 10:31:25 su squid[929]: Squid Parent: child process 1009 started
>
>Если pipe заменяю на обычный лог, то все работает.
>
>Очень надеюсь на помощь.

Сие сообщение значит, что ваш парсер отваливается от трубы по какой-то причине, скорее всего по ошибке, и на другом конце у сквида выскакивает сигнал  SIGPIPE. То есть надо искать причину в парсере. Скорее всего, там имеет место переполнение буфера при разборе слишком длинной строки лога.

Немного не по адресу вопрос: а зачем надо было менять лог-файл на трубу? Так основной функционал - проксирование - ставится в прямую зависимость от второстепенного,  и тем самым понижается общая надежность системы. Гораздо проще и надежнее периодически распарсивать и обнулять файл лога.
Когда я изобретал свой велосипед - считалку статистики сквида - я поначалу поступил так же, заменив лог-файл на трубу и повесив на него парсер. Однако после того, как осознав, что косяки парсера валят сам сквид, перешел на вариант с разгребанием и обнулением файла лога. Более того, я и от постоянного сидения парсера демоном отказался и стал дергать его из крона.

Удачи
PS: кстати, в своем парсере я таки решил проблему с разбором некорректных строк, уже 3 год он пашет и ни разу не свалился.
Если интересно, могу поделиться своим велосипедом.

"Проблема с access.log в pipe-канале (fifo)"
Отправлено Turbid , 19-Июн-07 18:10 
>Сие сообщение значит, что ваш парсер отваливается от трубы по какой-то причине

Хм, в том-то все и дело, что парсер не причем - я его вообще закоментировал на время в squid.sh, т.е. pipe никто не трогает кроме самого squid'а.

>надежнее периодически распарсивать и обнулять файл лога

А если хочется чтобы это было не периодически, а постоянно?

>Если интересно, могу поделиться своим велосипедом.

Буду очень признателен если поделитесь.


"Проблема с access.log в pipe-канале (fifo)"
Отправлено Newcomer , 20-Июн-07 11:01 
>>Сие сообщение значит, что ваш парсер отваливается от трубы по какой-то причине
>
>Хм, в том-то все и дело, что парсер не причем - я
>его вообще закоментировал на время в squid.sh, т.е. pipe никто не
>трогает кроме самого squid'а.
>
"It takes two to tango" -  в смысле чтобы писать в трубу, обязательно должен быть тот, кто в из нее читает. Концы трубы с обеих сторон должны быть открыты ( сис. вызов open() ).
Для сквида надо, чтобы читатель был запущен раньше него и висеть на трубе на вызове read(). Иначе вылетит ошибка по сигпайпу, что имеет место в вашем случае, либо, если оба конца открыты, писатель заблокируется, пока читатель не начнет из него читать (точно не помню).

>>надежнее периодически распарсивать и обнулять файл лога
>
>А если хочется чтобы это было не периодически, а постоянно?

Все зависит от того, какова допустимая задержка обновления информации в базе. Можно парсер дергать из крона хоть каждую минуту, и тогда актуальность данных в базе будет с точностью до  минуты.

У меня сейчас парсер вызывается раз в час, этого, в принципе хватает.


>>Если интересно, могу поделиться своим велосипедом.
>
>Буду очень признателен если поделитесь.

ТТХ велосипеда:
парсер, вызываемый из крона, пишет в базу на постгресе, далее, посредством SQL-ных скриптов, также вызываемых из крона, информация уплотняется - трафик и время группируются по сайту. Уплотненная информация складывается в долговременный архив daily_logs, подробная информация, накопленная за сутки, убивается.
При помощи sql-ных скриптов генерируются суточные, недельные и месячные отчеты, которые складываются на web-сервер и могут посылаться почтой.
Еще можно в указать friendly_nets, трафик из которых считать не требуется.

Все это добро в виде исходника парсера, набора sql-ных, шелловских скриптов и файла кронтаба. Из доков только небольшой readme.

Куда слать?

"Проблема с access.log в pipe-канале (fifo)"
Отправлено Turbid , 20-Июн-07 11:22 
Спасибо за помощь.

>Куда слать?
На мыло.


"Проблема с access.log в pipe-канале (fifo)"
Отправлено Turbid , 20-Июн-07 11:26 
turbidit[a]gmail.com


"Проблема с access.log в pipe-канале (fifo)"
Отправлено Turbid , 22-Июн-07 09:39 
>Куда слать?

К сожалению пока ничего та и не получаил. turbidit@gmail.com


"Проблема с access.log в pipe-канале (fifo)"
Отправлено rax , 30-Июн-07 14:54 
Я тоже написал чтобы логи SQUID складывались в MySQL используя pipe-канал, кому интересно могут скачать отсюда http://rrh.phpnet.us/