madf

жесткий ребут. гуевый ("виндовый"): 1.91.9 консольный: с пакета "Sgconf version: 1.08.9" меня смущает то, что по словам пользователя eric111 - "сбилось" у него все после 00-00 до этого все работало четко. А ночью никто не работал конфигуратором и не лазил к сервер -> следовательно что-то не так в логике сервера С каким именно конфигуратором проявлялась проблема? С логикой работы сервера все нормально т.к. он не использует эти данные. Совсем. Может у вас в 00:00 жесткий рестарт сервера по -9?

Еще, какая версия конфигуратора использовалась? Наблюдалась ли эта проблема с конфигуратором предыдущей версии?

Что такое "внезапный стоп"?

Жаждаю подробностей. Какая версия, какое хранилише используется? Я так понимаю все эти изменения делает какой-то скрипт? Может это он бочинит? И чем конвертировалось?

Как-то так: if [ "$param" = "tariff" ]; then export LANG=en_US.UTF-8 /etc/stargazer/plugins/sgconf/sgconf set -s 127.0.0.1 -p 5555 -a ******* -w ****** -u $login -m 'Уважаемый пользователь, ваш тариф '$oldValue', был изменен на '$newValue fi (ес-сно, вместо en_US.UTF-8 подставить свою локаль).

Собрать отладочную версию, сделать ulimit -c unlimited, воспроизвести баг, получить core-файл и заслать его мне вместе с бинарниками на faust@stg.dp.ua

sgconf пытается сконвертировать текст из текущей локали. Возможно что общесистемно локаль не установлена. Попробей сделать export LANG=<your_locale> перед вызовом конфигуратора.

Я то что, оно само ведь прошло. Жаль, конечно, что не удалось причину зунать.

Можно сделать нулевую абонку в тарифе, а в полночь кроном запускать скрипт который будет пробегать по всем пользователям и либо грепом из log (файловая база), либо запросом из tb_sessions_log проверять наличие коннектов за сегодня и снимать абонку в "ручном" режиме. Если нужна зависимость от тарифов - еще в тарифы заглядывать.

Такс. Я в этой версии конфигуратор не ломал, только ремонтировал. Проверь что у тебя от старой версии плагинов не осталось. И библиотек. И опиши свою конфигурацию. Патчи никакие на исходники не накладывал?

Можно тупо написать плагин в котором поставить нотификаторы на изменение freeMb и отключать/включать юзера. К стати очень простой плагин, даже без внутреннего потока. Буквально 2-3 функции. И будет вам реалтаймовость и все такое.

подозреваю что увидеть их можно только при помощи sgconfxml либо нативным конфигуратором. Есть чувствие что --d0 берет данные не из базы, хотя нада сорц посмотреть. Не из базы. Из памяти. Это ж данные за сессию, а не месячные.

Ну, это конечно гон уже писать раз в минуту стату. madf, не могли бы вы немного рассказать как СТЖ держит в памяти данные о трафике, и как можно было бы эти данные вытянуть - чисто для личного развития. Отчего ж не рассказать, раскажу. Очень просто держит. В приватных членах класса USER - шаблонных переменных типа USER_PROPERTY<тип> (см. user_property.h). Из методов класса USER (см. user.h) доступ можно получить непосредственно по именам, как это, например, сделано в методе записи статистики: int USER::WriteStat()

Очень даже логично - и тогда это решает вопрос с тем, что порог у тарифных планах разные. Но, вот как для красоты сделать, чтобы четко рубало при достижении порога. madf, если я не ошибаюсь, стж изначально держит трафик в памяти, потом при записи в стату - память обнуляется? Идея - но для этого нужно реализовывать отдельный процесс, которые будет всегда следить за трафиком - и этот же процесс будет рубать пользователя. Держит в памяти и не обнуляет при записи. Обнуляет в момент перехода через полночь или при отключении авторизатора. И то - только за сессию. Месачный обнуляется при

Для реалтайма надо установить нотификатор на изменения property.freeMb и при переходе через 0 выполнять действия. Но это значительное вмешательство в код. И да, он действительно пишет в соответстсвии со StatWritePeriod. И на 500 нормально, и на 6000 нормально. В т.ч. нормально на файловой базе и на PostgreSQL. По MySQL у меня данных нет, но думаю что и там нормально.

возникла мысль find-ом лазить в файл stat пользователя (БД - файловая). при достижении величины больше тарифного плана, то отключать пользователя. но как поступать, когда несколько тарифных планов с разной "абонплатой/объём трафика"? ЗЫ: я так понимаю ни у кого такой задачи не стояло. т.е. все (или большинство) просто продают трафик помегабайтно. у нас просто схема предоплаты 1го числа за определенный объём, а сверх лимита очень быстро деньги убегают. Зачем так сложно? В stat есть поле FreeMb. Сравниваем его с нулем и принимаем решение.

Это где? На сервере? На клиенте? Опишите топологию сети более детально. Где какие адреса и как они маршрутизируются в узловых точках.

Чесно говоря, ни разу такого не наблюдал. Если повторяется регулярно - прошу прислать бектрейсы отладочной сборки в момент проявления бага. Получить их можно так: $ gdb /path/to/stargazer (gdb) attach <pid_of_stargazer> ... (gdb) thread apply all bt (gdb) quit И прислать выхлоп мне на мыло: faust@stg.dp.ua. Попробую разобраться.

Вроде ничего не придумывается кроме как по крону опрашивать список на предмет отсутствия FreeMB и делать им disable. Ну еще можно подпатчить метод IsInetable в файле user.cpp чтобы он срабатывал по этому признаку.

Эта связка у нас используется на самом маленьком сервере в тестовом режиме уже почти год. В базе всего 900 юзеров, пиковый онлайн где-то 300 юзеров. Детальная статистика пишется для 76% онлайновых пользователей (отключена у большинства безлимитчиков). Раньше писалась для всех. Момент когда начали отключать установить не удалось, по этому тут данные не очень достоверные. Сейчас в базе данные начиная с 1 января 2010 года. База занимает 112 Гб на диске. Из них 96 Гб - таблица детальной статистики. В базу добавлено 3 дополнительных индекса по полям: tb_sessions_data.fk_session_log tb_detail_s

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

Каждый день.

Это проблема самого конфигуратора.

Любой меньше 2. Например 1.5.

rlm_stg поставляемый со Stargazer'ом не совместим с FreeRADIUS ветки 2