madf

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

Помозговали немного... Вот что пока придумалось (faust - я): По поводу протокола: если бы мы знали как его ускорить - думаешь, не ускорили бы? Точнее идеи по этому поводу есть, но в твоем случае это не поможет. У тебя для каждого юзера: - делается форк; - открывается TCP-сокет; - шифруется и отправляется XML; - принимается, дешифруется и разбирается XML; - закрывается сокет; - делается форк; - открывается TCP-сокет; - создается, шифруется и отправляется XML размером побольше; - принимается, дешифруется и разбирается XML; - закрывается сокет. Как думаеш, будет т

И сам запутался и меня запутал. Вот смотри: (gdb) r Starting program: /data1/admin/Distr/stg-2.404.9.7/projects/convertor/convertor Тут ты запустил его без указания конфига. По этому он взял его из стандартного места: ./convertor.conf Код ниже показывает, что источником данных послужила пустая дэфолтная база. (gdb) r ./ Starting program: /data1/admin/Distr/stg-2.404.9.7/projects/convertor/convertor ./ Тут ты запускаеш его с явным указанием конфига. Да, это уже моя ошибка была, т.к. сам конфиг не указан - указан только путь к нему. Но в отличие от stargazer он не ищет файл с конфиг

Ну я скрипта не видел... Но вобщето протокол конфигуратора достаточно медленный Почему конвертор не заюзал?

2Silitra: Вот буфер: map<RAW_PACKET, PACKET_EXTRA_DATA> packets; // Дерево в котором собраны пакеты одного типа а вот - индекс к буферу: typedef map<RAW_PACKET, PACKET_EXTRA_DATA>::iterator pp_iter; multimap<uint32_t, pp_iter> ip2packets; // Индекс адресов, указывающих на соответствующие пакеты

Уже кто-то об этом говорил. Грабли неизвестно где, т.к. падает на использовании API FreeRADIUS. К стати, в прошлый раз тоже было на 6-й фре, если не ошибаюсь.

1. Как я уже говорил - это проблемы загрузчика плагинов. Будут исправлены в след версии. Бага не влияет на результаты работы. 2. Нету смысла в буфере, т.к. внутри stg и так есть буфер. 3. Предполагаю - из-зи блокировок. FlushAndRemove останавливается на захвате мьютекса. 4. Может. Может быть мы так и сделаем. Если реализуешь, протестируешь и покажешь что это действительно дает выиграш в производительности - будем благодарны 5. А кто говорил про сложность организации? Почему многие считают, что для многопроцессорных систем надо выполнять какие-то телодвижения? Stargazer и так работает в не

1. Это не то, т.к. небыло сегфолта, а было корректное завершение работы. Но уже и не нужно, все что хотел - я увидел. 2 и 3. Знать неправильные настройки. Поподробнее - в документации.

Если эти модули ядра есть - да.

1. А где же bt? 2. Судя по тому что упало при delete toStore - преобразование базы завершено. Падения на деструкторе есть, я это признаю, я знаю их неявную причину, я не могу предложить воркераунда и обещаю исправить это в будущих версиях. С другой стороны - этот сегфолт не портит данных и не влияет на результаты работы программы. 3. Да, с параметром ошибся. Но в любом случае - тебе виднее где у тебя конфиг лежит

1. Я же говорил 2. Буфер не обезопасен мьютексом. Что произойдет, если при флаше в буфер добавятся данные? 4. У неавторизованных пользователей может накапливаться статистика. 5. Потоки распределяются между процессорами ядром.

Если ты не сделаешь modprobe iptable_filter (и это не сделает iptables за тебя автоматически) - у тебя не будет доступна таблица filter. Если ты не сделаешь modprobe ip_queue (и это не сделает iptables за тебя автоматически) - у тебя не будет доступна цель QUEUE. Я не понимаю, чем так плохо сделать два вызова modprobe. PS: если это чем-то не устраивает - никто не запрещает вкомпилить код этих модулей в ядро.

Тогда запусти из-под gdb: # export LD_LIBRARY_PATH=../../lib # gdb ./convertor ... (gdb) r ./ ... и когда упадет - покажи вывод команды bt.

1. Я имел в виду что в 146 строке файла netflow_cap.h ничего нет 2. На время FlushAndRemove лочатся все операции с деревом пакетов. Соответственно - и вызовы от cap-модулей. А что за буфер? 3. Перестает? Интересно... 4. Стата есть у всех. 5. Это сложно.

Уже обсуждалось и уже исправлялось. http://stg.dp.ua/download/sgconfig/1.90.9/....1.90.9.win.exe

Вот! Вот этот дядя с большими ушами! Не туда смотрите. Ошибка тут: #1 0x283f30ba in ~FLOW_CAP (this=0x284152e0) at netflow_cap.h:146 Но, подозреваю, - там пусто. А это значит - неправильно срабатывает *_CREATOR. Я уже сталкивался с этим и мы с Борей обсуждали это. В будущем схема работы с плагинами несколько изменится. Воркераунда пока нет, но и данные это падение не портит, т.к. происходит в самом конце, когда жизненно-важные операции уже завершены.

Не влияет. Влияет то, что ты используеш модули из /usr/lib/stg, а не из ../stargazer/modules

Да, конечно. В 405-й была обновлена библиотека DOTCONFpp. В частности - очепятка в слове "CASEINSENSITIVE" - "CASEINSENSETIVE". Замените это слово в указанной строке и все соберется.

Думаю, вопрошающий имеет в виду оплату услуг путем отсылки SMS.

Берем исходники нового конвертора. Ложим его в дерево исходников stg версии 2.404.9.7. Собираем. После этого должен работать как часики.

То что привели вывод gdb stargazer stargazer.core - это хорошо. Но было бы еще неплохо увидеть вывод команды bt (gdb)

Патч №1: Index: projects/stargazer/plugins/authorization/inetaccess/inetaccess.cpp =================================================================== RCS file: /cvsroot/stargazer/stargazer/plugins/authorization/inetaccess/inetaccess.cpp,v retrieving revision 1.57 diff -u -B -u -8 -p -r1.57 inetaccess.cpp --- projects/stargazer/plugins/authorization/inetaccess/inetaccess.cpp 30 Mar 2008 13:51:31 -0000 1.57 +++ projects/stargazer/plugins/authorization/inetaccess/inetaccess.cpp 14 Aug 2008 13:43:20 -0000 @@ -195,17 +195,18 @@ FREEMB AUTH_IA_SETTINGS::GetFreeMbShowTy return freeMbShowType; } /

Лог получен, решение найдено. Тестирую...

Без bash сборка не работает.

А почты все нет и нет...