madf

На самом деле вполне резонный вопрос. Таблица на 4000 записей - это несерьезная нагрузка для базы. Выборка будет происходить быстро (по крайней мере в Firebird и PostgreSQL мне доводилось работать и с большими таблицами). Старгейзер сейчас держит в памяти большое количество неактуальной информации, которую можно было бы вытягивать из базы по запросу. PS: вроде-бы у кого-то Stg работает на 3000 юзерах.

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

Программа уже установлена. Не скопировался только конфигурационный файл (неправильный путь). Просто руками кинь 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: //------------------------------------------

По первому. Перехватчики сигналов определены в 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, &olds

А, ну все понятно. 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 rea

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

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

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

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

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

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

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

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

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