madf

Да, очепятка в исходниках. Добавил в "список-того-что-нужно-сделать"

Программа уже установлена. Не скопировался только конфигурационный файл (неправильный путь). Просто руками кинь sgauth.conf из каталога с исходниками в какое-нибуть удобное место. Запускать указывая в качестве параметра путь к конфигу (это важно - автоматически он попытается открыть файл /etc/stauth.conf - очепятка). Добавил себе в TODO

Откуда и куда конвертиш? Исходники, бинарники и корку, если не сложно, упакуй и закинь в faust@stg.dp.ua

Лог make install, плиз. Ну и можно вручную файлик sgauth скопировать в /usr/bin, а файлики из lib - в /usr/lib/stg

Нафига такой геморой? Проще по умолчанию разрулить фаерволом

Зависания компилятора - проблемы разработчиков компилятора. Это не к нам.

Какая древность... Сейчас sgauth идет в пакете со старгейзером. У него свои build и Makefile

Эти два сообщения на самом деле ни ошибки ни предупреждения. Это я оставил для напоминания о том, что в данном месте пришлось написать неочевидный код, т.к. старый приводил к краху компилятора на 64-битных системах. Так что они тут совершенно не при чем.

На OnDisconnect не "выключать" это направление и все.

Скорее всего потому что за 5 сек не успевает сохраниться инфа в базе.

2Stiff: баг подтвержден. Ошибка в конфигураторе. Поправляем.

1. На RSDN все написано верно. 2. В цитате все написано верно. Проблема заключается в том, что ты действительно, видимо, не понимаеш, как работает Stargazer. На самом деле все просто. Обработчик сигналов у нас 1 на все приложение, а не для каждой нити. Практически все нити "висят" на блокирующем read. Также есть главный цикл, который раз в 100 мс проверяет необходимость перезагрузки правил. Когда происходит прерывание по сигналу - вызывается обработчик. В како нити это произошло - не важно. Обработчик работает с глобальным объектом nonstop: //----------------------------------------------------------------------------- class STG_STOPPER { public: STG_STOPPER() { nonstop = true; } bool GetStatus() { return nonstop; }; void Stop(const char * __file__, int __line__) { #ifdef NO_DAEMON printfd(__FILE__, "Stg stopped at %s:%d\n", __file__, __line__); #endif nonstop = false; } private: bool nonstop; }; //----------------------------------------------------------------------------- STG_STOPPER nonstop; //----------------------------------------------------------------------------- После вызова метода Stop этого объекта обработчик завершает свою работу и управление передается обратно в точку прерывания. Максимум через 100 мс главный цикл проверит условие выхода (в нем нет блокирующих вызовов) и завершится. После этого начинается процесс останова системы, который обсудили выше (dummy packets vs. pthread_kill). По поводу необходимости вызова pthread_join я уже писал выше: потоки создаются 1 раз (при старте программы) и завершаются 1 раз (при останове). Утечки памяти не происходит. Я не вижу никаких потиворечий в обработке сигналов с тем, что написано по указанным тобой ссылкам. И не понимаю, почему ты считаеш, что Stargazer не может работать.

По первому. Перехватчики сигналов определены в main.cpp. В частности, CatchTERM: void CatchTERM(int sig) { /* *Function Name:CatchINT *Parameters: sig_num - номер сигнала *Description: Обработчик сигнала INT *Returns: Ничего */ STG_LOGGER & WriteServLog = GetStgLogger(); WriteServLog("Shutting down... %d", sig); //nonstop = false; nonstop.Stop(__FILE__, __LINE__); struct sigaction newsa, oldsa; sigset_t sigmask; sigemptyset(&sigmask); sigaddset(&sigmask, SIGTERM); newsa.sa_handler = SIG_IGN; newsa.sa_mask = sigmask; newsa.sa_flags = 0; sigaction(SIGTERM, &newsa, &oldsa); sigemptyset(&sigmask); sigaddset(&sigmask, SIGINT); newsa.sa_handler = SIG_IGN; newsa.sa_mask = sigmask; newsa.sa_flags = 0; sigaction(SIGINT, &newsa, &oldsa); } отвечает за обработкe сигналов SIGTERM и SIGINT: /////// sigemptyset(&sigmask); sigaddset(&sigmask, SIGTERM); newsa.sa_handler = CatchTERM; newsa.sa_mask = sigmask; newsa.sa_flags = 0; sigaction(SIGTERM, &newsa, &oldsa); ... /////// sigemptyset(&sigmask); sigaddset(&sigmask, SIGINT); newsa.sa_handler = CatchTERM; newsa.sa_mask = sigmask; newsa.sa_flags = 0; sigaction(SIGINT, &newsa, &oldsa); Приводит к останову главноого цикла: while (nonstop.GetStatus()) { if (needRulesReloading) { needRulesReloading = false; traffCnt->Reload(); } stgUsleep(100000); } За которым следует код остановки всех подсистем. Все порождаемые stg нити работают от старта до останова системы. По этому, даже если после их завершения остались неосвобожденные ресурсы (тут я согласен, по документации joinable threads оставляют ресурсы до pthread_join) - они буду освобождены ОС, т.к. после останова потоков программа завершает свою работу. Да, во многих потоках которые блокируются на прослушке порта останов реализован посылом dummy packet. Хорошее или плохое это решение - хз. Ничем не хуже посыла потоку сигнала (pthread_kill), который приведет к снятию блокировки с возвратом -1 и errno = EINTR.

А, ну все понятно. fpc - FreePascal? То у тебя паскаль так с нитями дружит. PS: проверил тот-же пример на FreeBSD 5.3-RELEASE с теми-же результатами

Какие-то ты страшные страсти рассказываеш про joinable threads. Написал небольшое тестовое приложение: создает дэфолтную нить, ждет 5 сек и завершается. Нить тупо считает сумму чисел до 1000000 с периодическим выводом и завершается (раньше 5 сек). Запустил у себя на Gentoo Linux - отработала нормально. Пустил под valgrind: ==6476== malloc/free: in use at exit: 68 bytes in 1 blocks. ==6476== malloc/free: 1 allocs, 0 frees, 68 bytes allocated. ==6476== LEAK SUMMARY: ==6476== definitely lost: 0 bytes in 0 blocks. ==6476== possibly lost: 68 bytes in 1 blocks. ==6476== still reachable: 0 bytes in 0 blocks. ==6476== suppressed: 0 bytes in 0 blocks. - все как и описано в документации (pthread_join не делал). Собрал и запустил на FreeBSD 4.6-RELEASE-p2 с библиотекой libc_r. Отработало так-же как и под Gentoo Linux. Сейчас еще на 5-й попробую. На какой версии фри и с какой либой у тебя глюки вылезали?

По поводу выполнения скриптов. Не понимаю, какой смысл открывать пайп через popen, если нам не нужен stdout скрипта. Почему такая сложная схема реализована в stg? Потому что совместная работа fork и POSIX Threads вызывала немыслимые глюки на старых ядрах.

2vovksextra: За развернутый пост спасибо, анализирую. По поводу буфера ты не совсем прав, т.к. если скорость обработки ниже скорости приема любого размера буфер когда-нибуть заполнится. По поводу joinable-threads тоже не совсем так. Единственная "фишка", которая происходит если не сделать join - "утечка" памяти. Но, т.к. это происходит при останове программы - оно никак не влияет на систему. После останова вся память распределенная программе будет освобождена ОС. Потеря данных при kill, если поток не остановился за 5 сек? Ну что ж, можно таймаут сделать конфигурабельным. 2Stiff: Сегодня проверю.

Такого рода запросов еще небыло. Ничего пока не могу сказать.

Ну тогда пока ничего не могу сказать. Под рукой нету тестовой машинки с ASP

По первому - ничего не могу сказать. Фря - странная и загадочная система. Как при более жестком условии в счетчик может попасть больше пакетов чем при более мягком - ума не приложу. По второму: кроме модулей есть еще динамические библиотеки. Без них система рабоать не может. По умолчанию используются те, которые лежат в /usr/lib/stg. Чтобы использовать библиотеки из другого места нужно записать в переменную окружения LD_LIBRARY_PATH путь к библиотекам. Так, например, для запуска старгейзера из каталога сборки в конфиге путь к модулям прописывается ./modules, а сам он запускается командой: LD_LIBRARY_PATH=../../lib ./stargazer

Возможно все кроме этого. И модули тут не помогут. И в ветке 2.x этого не будет.

На самом деле основная работа - это классификация перехваченного пакета. Кому он принадлежит. Потом остается только элементарная операция сложения, которая особо никого не нагружает. Так что выключать обсчет трафика бессмысленно. В следующей версии добавлена опция отключения записи детальной статистики для отдельных юзеров. Это, ИМХО, более нужная и уже давно востребованная фича.

Причина сообщений - именно в "мусорных" файлах deps. А вот причина того, что в них оказывается мусор - может быть и такая.

причина таких сообщений - "мусорные" файлы deps, которые остаются после неуспешных сборок. Или перераспакуйте исходники или вручную их поудаляйте. make clean тоже должен помочь.

А можешь описать рецепт?