Genius

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

Подтверждаю, неприятная вещь, давно вроде тянется.

Спасибо за подсказку фикса со временем в debug режиме. Возникла еще одна ошибка при переходе на новый месяц 1го числа: Модуль FB, статистика по новому месяцу вроде добавилась корректно, а вот по старому при этому сохранилась неправильно, а именно: stats_date = 31.10.0107 получился, при том что должен был быть 30.11.2007 Новая статистика как и должна была создалась 12.01.2007

Дело не в приходе данных, для быстрой и простой проверки проблемы достаточно просто первести системные часы во время работы stg, время в биллинге у меня остается старым.

Сборка последняя выложенная в этой теме, собрана в debug`е Ну я тоже заметил только спустя несколько недель после использования новой сборки, потому что до этого сервер часто ребутать приходилось. Из модулей netflow, radius. Возможно что netflow система создания задержки отключения пользователя создает такой эффект? Дополнительный паузы в каких-то тредах могут создать такой эффект?

Обнаружилась интересная ошибка со временем: В предыдущей сборке сервер периодически синхронизировал время с временем системы или постоянно использовал его, во всяком случае при переводе времени системы время в биллинге тоже переводилось На данный момент время расходится причем довольно быстро (время на сервере синхронизируется ntpd и имеется drift 72s), биллинг за 2 дня отстал на 30мин примерно. Думаю правильное решение вернуть старую схему работы со временем. П.С. Баг критичный так как тарифы завязаны на времени. Если не сложно в таких случаях выкладывать исправления небольшим

Последняя сборка со всеми правками написанами здесь + radius + netflow + некоторые собственные дополнения нормально крутиться уже 2 недели на 500 юзеров, вроде все ок. Inetaccess не пользуем, хранилище firebird.

В stg_timer.cpp объявлен debug времени для запуска за 3 минуты до конца месяца, видимо забыли убрать. Замените строчку #define STG_TIMER_DEBUG (1) в самом начале этого файла на //#define STG_TIMER_DEBUG (1) и все будет нормально.

Переходите на Radius авторизацию и не будет проблема с подменами. Кроме того ВПН самый простой способ раздавать юзерам реальные ипишники.

Если смотреть варианты решения этой проблемы в том же УТМе, то там есть возможность сжать детализацию до суточной. То есть аггрегировать все 10минутные данные, в набор IP адресов посещенный за сутки и суммарные объемы данных по адресам, проводить эту операцию например над записями старше 30 дней (опционально запуск SQL запроса по крону). Ну и для еще более старых записей действительно упаковывать. У нас на 300 юзерах данные растут на 300-500Мб в сутки, но без детализированных данных вообще обойтись нельзя, во первых есть органы, во вторых иногда сложно доказать абоненту откуда траффик.

Написали же что пользовательских скриптов в новом биллинге больше нет как факта, и тебе уже предложили вариант решение этой проблемы.

Значит проблема одинаковая, просто в вашем случае время уходило вперед а в моем назад, спасибо за ваш опыт, я у себя тоже поправил синхронизацию и ход часов.

Наткнулся на аналогичный косяк: DayFee = 1 DayResetTraff = 1 При перехорде август/сентябрь все было ОК Сейчас при переходе на октябрь первый раз снялось 1го октября в 00:00 как и должно быть, второй раз снялось 1го октября в 23:51 Что за мистика - непонятно, есть подозрение что связано с тем что ntpdate в 00 синхронизирует и незначительно сдвигает время (в моем случае назад на несколько минут) что может вызвать какие то косяки. Сборка последняя от 20го сентября + FireBird + netflow + radius. При тестировании и перепроходе даты заново повторить не удалось ни разу.

Конфигуратор в стг, как я понимаю, работает довольно хитро и криво, то есть одновременно отдача данных нескольким конфигураторам невозможна, но соединения он принимает всегда и просто тупо подвисает второй подключившийся до момента окончания отдачи данных первому. У меня часто случается такой конфликт у параллельно работающих кассиров. Надо просто переписать всю работу с конфигураторами на полностью параллельную обработку.

Да, прошу прощение, бага действительно в версиия 26.06. С user_data да, именно так, значит ждем firebird2.1 stable

Новая ошибка в модуле FB Нет экранирования переменных, при попытка сохранения поля note вываливается ошибка если разместить там ' В других вариантах не проверял, думаю надо просто везде экранировать спецсимволы.

На данный момент число полей все равно получается всегда 10 ввиду конфигуратора, а если реализуется концепция любого числа полей то тем более надо искать какое то новое решение, например с триггерами FB.

Stargazer сколько мне известно не собирается под x86_64

http://local.com.ua/forum/index.php?showtopic=8241&st=45 Вот ошибка, выделенная там строчка действительно не выполняется, printfd вставленные дальше не выводяться уже.

Что ж, еще лучше, тогда сегодня вечером представлю ему свои выводы, да и еще наверное к тому времени будет более подробно понятно место где происходит падение.

Итак, после длительных тестов и выводов дополнительной отладочной информации могу довольно уверенно утверждать что баг связан с модулем netflow: radius_ia.cpp > 22:42:35 > Found IP (192.168.1.60) in request start-packet of user tushkanchik. radius_ia.cpp > 22:42:35 > Trying to authorize user: radius_ia.cpp > 22:42:35 > Login: tushkanchik radius_ia.cpp > 22:42:35 > IP: 192.168.1.60 radius_ia.cpp > 22:42:35 > Interface: radius / MikroTik (192.168.100.2) / 3032 / 00:0A:E4:BE:AF:D6 user.cpp > 22:42:35 > Authorize 1 us

Переработал целиком систему сохранения userdata чтобы они сохранялись Update запросами, это снижает нагрузку, не растут индексы полей, и нет косяков с тем что количество полей увеличивается. Перенес Insert запросы в UserAdd И заменил Insert на Update в SaveConf и добавил внесение в базу правильного num. --- firebird_store_users.cpp 2007-09-14 15:06:02.000000000 +0400 +++ firebird_store_users.cpp.new 2007-09-23 00:20:35.000000000 +0400 @@ -166,6 +167,18 @@ return -1; } } + + for (i = 0; i < 10; i++) + { + strprintf(&query

Ошибка модуля FB (или недоработка) Ошибка связана с полями userdata При сохранении в базу у полей не проставляет поле num, то есть все идут с 0 номером, принципиально это ничего не меняет так как сортировка все равно идет правильно и загружаются они в той же последовательности, НО при некорректной остановке старгейзера (которая иногда неизбежно случается) в базе могут накапливатся неудаленные или лишние поля userdata, в результате они: 1. Путаются, баг визуально заметен, иногда поля у юзеров уползают на 5-6 userdata 2. Накапливаются старые поля и складируются в базе, не заметно,

Косметический баг в модуле FB, был на прошлой версии, но не успел зарепортить. При запуске биллинга все метки времени в базе (время последнего логина и последних денег) уползает вперед на 2-4 часа (точно не замечал, но все время постоянный фактор), думаю что тупо связано с timezone сервера.

Чего то не все ошибки подправлены, при беглом просмотре осталось: - Неправильны формат поля freemb в базе и при сохранении, не пишется дробная часть да и в формате БД не предусмотрена она. - Не решена проблема с буквой Z если она первая в логине, имени тарифа. Глубже пока не тестировал, неприятно осознавать что к подробным багрепортом, иногда и с патчем для исправления, относятся не очень внимательно.