Сбор багов и feature requests

[Ork Yason]

опять же смотря что там героически хранить...

данные о сессиях - ими можно пожертвовать...

важны финансовые данные... а эти данные зависят от кол-ва пользователей и постоянны в своем объеме

[madf]

ещё заметил такую вещь, была всего раза 2 за последние 2-3 месяца, stg работает, авторизатор и конфигуратор подключается, правила создаются, но ниодного байта не пропускается, помогает исключительно рестарт биллинга

а каким местом stg по вашему вообще связан с "пропуском трафика"?

Если перехват с IPQ - то непосредственно.

да, через IPQ

 

Это на 2.407-rc1?

Если да то прошу собрать в отладочном режиме и сделать следующее (когда этот баг снова проявится):

$ gdb /path/to/stargazer
(gdb) attach <stargazer's_pid>
(gdb) thread apply all bt

Выхлоп последней команды заслать мне на faust@stg.dp.ua.

Если используется более ранняя версия - прошу подтвердить этот баг на 2.407-rc1.

[madf]

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

пусть даже после некоторого времени когда у него кончится место в памяти пусть героически падает, но не сразу же после падения связи с мускулом

 

Не, героически падать не нужно. Можно просто начать терять старые данные. Но этого пока не реализовано. Сейчас он будет героически работать пока не съест всю память и ядро не прибъет его OOM Killer'ом.

[yKpon]

да, через IPQ

 

Это на 2.407-rc1?

Если да то прошу собрать в отладочном режиме и сделать следующее (когда этот баг снова проявится):

$ gdb /path/to/stargazer
(gdb) attach <stargazer's_pid>
(gdb) thread apply all bt

Выхлоп последней команды заслать мне на faust@stg.dp.ua.

Если используется более ранняя версия - прошу подтвердить этот баг на 2.407-rc1.

в этой версии пофиксено это? http://local.com.ua/forum/topic/21317-novii-mesjac-i-ne-snjalas-abonplata-nekotorih-juz/page__view__findpost__p__160807

Не, героически падать не нужно. Можно просто начать терять старые данные. Но этого пока не реализовано. Сейчас он будет героически работать пока не съест всю память и ядро не прибъет его OOM Killer'ом.

то есть в последней версии модуль работы с MySQL уже исправлен?

[madf]

да, через IPQ

 

Это на 2.407-rc1?

Если да то прошу собрать в отладочном режиме и сделать следующее (когда этот баг снова проявится):

$ gdb /path/to/stargazer
(gdb) attach <stargazer's_pid>
(gdb) thread apply all bt

Выхлоп последней команды заслать мне на faust@stg.dp.ua.

Если используется более ранняя версия - прошу подтвердить этот баг на 2.407-rc1.

в этой версии пофиксено это? http://local.com.ua/forum/topic/21317-novii-mesjac-i-ne-snjalas-abonplata-nekotorih-juz/page__view__findpost__p__160807

2.407-rc1 от 19 апреля, а эти патчи были позже. В принципе они подойдут для 2.407-rc1.

 

Не, героически падать не нужно. Можно просто начать терять старые данные. Но этого пока не реализовано. Сейчас он будет героически работать пока не съест всю память и ядро не прибъет его OOM Killer'ом.

то есть в последней версии модуль работы с MySQL уже исправлен?

Нет. MySQL я не трогаю. Вышеописанное относится к FireBird и PostgreSQL.

[trinux]

stargazer[16667]: segfault at 8 ip b6ce7035 sp b68f3100 error 4 in mod_store_mysql.so[b6cd8000+23000]

 

 

 

что посоветуете сделать?

[madf]

stargazer[16667]: segfault at 8 ip b6ce7035 sp b68f3100 error 4 in mod_store_mysql.so[b6cd8000+23000]

 

 

 

что посоветуете сделать?

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

[keshaLG]

доброго времени суток уважаемые коллеги!

Используем stg-2.407-rc1 с хранением в базе postgresql (кстати, мегареспект за данный релиз - очень стабильно и удобно с базой) ,

нарисовали статистику пользовательскую, где есть вывод выборки "10 последних операций со счетом" из таблицы tb_params_log,

возник вопрос:

почему stg не пишет факт снятия абонплаты в данную таблицу, а только в свой лог?

 

И что/где нужно поправить что бы писал, а то как-то нехорошо выходит: у юзеров в статистике только их пополнения.

[madf]

доброго времени суток уважаемые коллеги!

Используем stg-2.407-rc1 с хранением в базе postgresql (кстати, мегареспект за данный релиз - очень стабильно и удобно с базой) ,

нарисовали статистику пользовательскую, где есть вывод выборки "10 последних операций со счетом" из таблицы tb_params_log,

возник вопрос:

почему stg не пишет факт снятия абонплаты в данную таблицу, а только в свой лог?

 

И что/где нужно поправить что бы писал, а то как-то нехорошо выходит: у юзеров в статистике только их пополнения.

А есть ли в базе в таблице tb_admins админ с логином "@stargazer"? Если его нет - это причина. Нужно добавить вручную. В поле пароля можно забить "NO_PASSWORD", а в остальные поля нули. Тогда доступа для админа с таким логином не будет (а в слудующих версиях я его просто фильтрую), но журналирование будет работать.

В скриптах для базы уже исправил.

[keshaLG]

где-то так?

[root@stg stargazer]# psql -U postgres -d stg -A -c "select * from tb_admins where login='@stargazer'"
pk_admin|login|passwd|chg_conf|chg_password|chg_stat|chg_cash|usr_add_del|chg_tariff|chg_admin|chg_service|chg_corporation
7|@stargazer|fcohajolfpfnimnoflnijbfigfoldkblmmefahbbbfbmpkmkmmefahbbbfbmpkmk|0|0|0|0|0|0|0|0|0
(1 запись)
[root@stg stargazer]#

[madf]

где-то так?

[root@stg stargazer]# psql -U postgres -d stg -A -c "select * from tb_admins where login='@stargazer'"
pk_admin|login|passwd|chg_conf|chg_password|chg_stat|chg_cash|usr_add_del|chg_tariff|chg_admin|chg_service|chg_corporation
7|@stargazer|fcohajolfpfnimnoflnijbfigfoldkblmmefahbbbfbmpkmkmmefahbbbfbmpkmk|0|0|0|0|0|0|0|0|0
(1 запись)
[root@stg stargazer]#

Добавил или он там был?

[keshaLG]

Добавил или он там был?

вчера добавил по вашему совету,

изначально в стартовом дампе был только просто "admin"

[madf]

Добавил или он там был?

вчера добавил по вашему совету,

изначально в стартовом дампе был только просто "admin"

Ну теперь по идее должно нормально журналировать.

[keshaLG]

спасибо, ждем первого

PS обязательно отпишусь о результатах

[trinux]

Вот такая шняга шняжная сегодня у меня приключилась

 

 

старгейзер не стартует в логе вот что

 

root@slackware:/etc/stargazer# dmesg

stargazer[10270]: segfault at 8 ip b6c8e049 sp b6949100 error 4 in mod_store_mysql.so[b6c7f000+23000]

stargazer[10296]: segfault at 8 ip b6c7d049 sp b6938100 error 4 in mod_store_mysql.so[b6c6e000+23000]

stargazer[10320]: segfault at 8 ip b6c79049 sp b6934100 error 4 in mod_store_mysql.so[b6c6a000+23000]

stargazer[10338]: segfault at 8 ip b6c2a049 sp b68e5100 error 4 in mod_store_mysql.so[b6c1b000+23000]

stargazer[10419]: segfault at 55 ip b765017b sp b696f13c error 4 in libc-2.7.so[b75de000+146000]

stargazer[10672]: segfault at 8 ip b6daa049 sp b6a65100 error 4 in mod_store_mysql.so[b6d9b000+23000]

stargazer[10716]: segfault at 8 ip b6cbe049 sp bfae1b60 error 4 in mod_store_mysql.so[b6caf000+23000]

stargazer[10872]: segfault at 8 ip b6c05049 sp b68c0100 error 4 in mod_store_mysql.so[b6bf6000+23000]

stargazer[10894]: segfault at 8 ip b6d7e049 sp b6a39100 error 4 in mod_store_mysql.so[b6d6f000+23000]

stargazer[10912]: segfault at 8 ip b6dbc049 sp b6a77100 error 4 in mod_store_mysql.so[b6dad000+23000]

stargazer[10930]: segfault at 8 ip b6c27049 sp b68e2100 error 4 in mod_store_mysql.so[b6c18000+23000]

stargazer[10975]: segfault at 8 ip b6cf6049 sp b69b1100 error 4 in mod_store_mysql.so[b6ce7000+23000]

 

 

 

 

в логе биллинга

 

2010-11-15 11:20:52 -- Stg v. 2.406

2010-11-15 11:20:52 -- Message queue created successfully. msgKey=5555 msgID=851968

2010-11-15 11:20:52 -- Timer thread started successfully.

2010-11-15 11:20:53 -- Storage plugin: mysql_store v.0.67. Loading successfull.

2010-11-15 11:20:53 -- Users started successfully.

2010-11-15 11:20:53 -- Traffcounter started successfully.

2010-11-15 11:20:53 -- Module: 'CAP_NF v. 0.3'. Start successfull. 0

2010-11-15 11:20:53 -- Module: 'Ether_cap v.1.1'. Start successfull. 10

2010-11-15 11:20:53 -- Module: 'InetAccess authorizator v.1.3'. Start successfull. 50

 

 

 

пересобрал, не помогло.

[madf]

Какие-то проблемы с базой. Я предупреждал что модуль для MySQL очень нестабилен.

[Zero_real]

Пожелание:

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

[egor2fsys]

Пожелание:

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

 

А к имени тарифа нельзя привязаться ?

[Kucher2]

Пожелание:

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

А зачем Вам это?

У меня например в OnConnect идёт проверка какой тариф у юзера и соответственно тарифу юзер пихается в определённую таблицу. Как у Вас реализовано? Просто интересно.

 

egor2fsys опередил.

[madf]

Пожелание:

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

Конечно неправильно! Лучше завести отдельную таблицу (или файл для файловой базы) связанную с тарифами по внешнему ключу, в которой и указывать эти параметры.

[Небесный]

Вот у меня есть некая функция, которая вытягивает из тарифа скорость.

А, еще что забыл, в названии тарифного плана, должна стоять скорость, например:

tariff_128 - получим 128 кбит

tariff_1024 - получим 1 Мбит

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

 

function fspeedkb()
{
       ftariff=$1

       # С имени тарифного плана вытигиваем скорость в килобитах
       speed=$(echo "$ftariff" | sed "s/[^0-9]//g")

       # Если мы получили какие-то цифры - назначим переменной fspeedkb скороть в битах (я просто работаю с шейпером в битах, кто-то в кбитах)
       if [ "$speed" != "" ]
       then
         fspeedkb=$(($speed * 1024 )) # Дневной тариф
       fi

       # Если мы с тарифа не получили никаких цыфр, тогда переменной fspeedkb назначим дефолтную скорость 
       if [ "$speed" = "" ];
       then
               fspeedkb=65536
       fi

       echo $fspeedkb"bit"
}

# Через функцию fspeedkb() из тарифного плана  узнаем скорость для шейпера
# функция работает: извлекает числовое значение из тарифного плана,
# это число идет килобитах, чтобы получить в битах - умножаем на 1024
speedkb=`fspeedkb $tariff`

 

Отдельное благодарство madf, за помощь в разработке этой функции.

[Kucher2]

Увы, но например у меня существует несколько разных тарифов, где скорость "туда и обратно" - отличается, поэтому мне проще фильтровать в OnConnect всё это. Но за идею спасибо.

[Небесный]

Ну, да. Просто у меня ап-линка хватает с головой, не вижу для себя смысл резать по другому аплинк.

[Zero_real]

Да не вопрос. А теперь обьясните это персоналу, который по разным причинам не может/не хочет с этим всем заморачиваться. Я могу и вебморду управления тарифами накодить, где будут эти поля, которые будет пихаться в отдельную таблицу, но почему бы не добавить этот функционал прямо в кофигуратор? Сейчас почти все покупают анлимы, функции порогов по трафику и разной цены взависмости от времени суток в стг есть, хотя они все менее актуальны. Так почему бы не добавить столь простой и нужный функционал? Неудобно управлять системой с разных мест.

 

Да и не только скорость можно будет включать в эти поля. Например та же доступность/не доступность сервисов для пользователей конкретного тарифа вполне может включаться через эти поля. Удобно.

[Небесный]

Хм, коды вроде бы откритые - что мешает пилять под себя?