Начал подвисать конфигуратор

[laffytaffy 84]

собственно конфигуратор версии

 

при добавлении пользователя подвисает (приложение не отвечает)

 

снимаешь задачу, запускаешь конфигуратор заново ошибка

 

чтобы зайти в него заново нужно ждать минут 5-10 и так по кругу, на добавление пользователя уходит минут 20-25

 

при редактировании любой учетной записи таже фигня

 

подскажите в чем бок?

[Prime 51]

поставь версию младше

[madf 279]

А после чего начал подвисать?

[laffytaffy 84]

А после чего начал подвисать?

 

 

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

 

может от количества пользователей...

 

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

[nightfly 1 221]

какая база/сколько юзверей? (чистое любопытство)

[laffytaffy 84]

какая база/сколько юзверей? (чистое любопытство)

 

мускул, ~230+

[nightfly 1 221]

Да не - не изза количества точно

 

 

Stg-2.406-rc1 ?

 

П.С. любопытно было вылезание косяков на 1к+ пользователей.

[laffytaffy 84]

Да не - не изза количества точно

 

 

Stg-2.406-rc1 ?

 

П.С. любопытно было вылезание косяков на 1к+ пользователей.

 

[Neelix 33]

Попробуй версию конфигуратора старее как сказали выше.

[madf 279]

На сколько стабильно работает консольный конфигуратор?

Судя по скрину используется модифицированная а не оригинальная версия. Может, проблема в этом.

 

Да не - не изза количества точно

 

 

Stg-2.406-rc1 ?

 

П.С. любопытно было вылезание косяков на 1к+ пользователей.

Что за проблема с 1к?

У местного провайдера работает уже на 4к без особых проблем (ну если не считать проблемой ужасно долгую загрузку списка юзеров в конфигураторе

[laffytaffy 84]

На сколько стабильно работает консольный конфигуратор?

Судя по скрину используется модифицированная а не оригинальная версия. Может, проблема в этом.

 

 

Что за проблема с 1к?

У местного провайдера работает уже на 4к без особых проблем (ну если не считать проблемой ужасно долгую загрузку списка юзеров в конфигураторе

 

 

поставил оригинальную sgconfig.1.90.9.win

 

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

 

с пользователя завтра проверю, изменил пару вроде норм, не виснет, завтра погоняю дольше

[egor2fsys 5]

поставил оригинальную sgconfig.1.90.9.win

 

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

 

с пользователя завтра проверю, изменил пару вроде норм, не виснет, завтра погоняю дольше

 

А как на счет включить отладку в сервере и приложить лог в момент подвисания конфигуратора ?

[Keen 10]

глюк подтверждаю. От версии конфигуратора или консольного конфигуратора не зависит.

Проявляется:

1. При добавлении нового пользователя.

Пользователь создается, конфигуратор подвисает. В итоге имеем что логин появился, пароль, айпишник и все остальные данные - пустые.

Лечится перезапуском демона старгейзера.

2. Само по себе.

Есть открытый кофигуратор, 1 минуту назад редактировали запись, добавляем денег на счет, конфигуратор подвисает.

После 5ти минутного ожидания получаем Recv header answer error.

Новые копии конфигуратора при конекте говорят connect failed.

 

Щаз соберу в дебаг режиме, попробую там что-то найти.....

[egor2fsys 5]

глюк подтверждаю. От версии конфигуратора или консольного конфигуратора не зависит.

Проявляется:

1. При добавлении нового пользователя.

Пользователь создается, конфигуратор подвисает. В итоге имеем что логин появился, пароль, айпишник и все остальные данные - пустые.

Лечится перезапуском демона старгейзера.

2. Само по себе.

Есть открытый кофигуратор, 1 минуту назад редактировали запись, добавляем денег на счет, конфигуратор подвисает.

После 5ти минутного ожидания получаем Recv header answer error.

Новые копии конфигуратора при конекте говорят connect failed.

 

Щаз соберу в дебаг режиме, попробую там что-то найти.....

 

 

Да, лог бы хотелось очень увидеть.

 

P. S.

 

Ну и не забываем о том, что модуль mysql-store не поддерживатся авторами в настоящее время и не рекомендован в качестве основного модуля работы c БД.

[Keen 10]

незнаю поможет или нет, но пока могу предложить следующее:

В данный момент конфигуратор висит

Конектится он к порту 5556.

 

localhost ~ # netstat -an | grep 5556

tcp 0 0 0.0.0.0:5556 0.0.0.0:* LISTEN

tcp 0 0 194.169.205.1:5556 95.69.194.120:1573 SYN_RECV

tcp 0 0 194.169.205.1:5556 95.132.191.173:3143 SYN_RECV

tcp 0 0 194.169.205.1:5556 77.41.7.130:3028 SYN_RECV

tcp 0 0 194.169.205.1:5556 95.69.194.120:1248 SYN_RECV

tcp 0 0 194.169.205.1:5556 89.185.88.238:2996 SYN_RECV

tcp 0 0 194.169.205.1:5556 77.35.129.129:2562 SYN_RECV

tcp 0 0 194.169.205.1:5556 92.101.178.226:4634 SYN_RECV

tcp 0 0 194.169.205.1:5556 92.113.149.224:4178 SYN_RECV

tcp 0 0 194.169.205.1:5556 82.114.232.240:1984 SYN_RECV

tcp 0 0 194.169.205.1:5556 91.124.43.118:4065 SYN_RECV

tcp 0 0 194.169.205.1:5556 95.133.115.180:4706 SYN_RECV

tcp 0 0 194.169.205.1:5556 85.174.45.126:3688 SYN_RECV

tcp 0 0 194.169.205.1:5556 89.178.9.234:55030 SYN_RECV

tcp 0 0 194.169.205.1:5556 82.63.251.172:2367 SYN_RECV

tcp 0 0 194.169.205.1:5556 213.251.205.38:1626 SYN_RECV

tcp 0 0 194.169.205.1:5556 212.106.41.147:3694 SYN_RECV

tcp 0 0 194.169.205.1:5556 78.12.198.120:1094 ESTABLISHED

tcp 69 0 194.169.205.1:5556 192.168.2.118:3570 CLOSE_WAIT

 

В логе valgrind следующее:

localhost stargazer # cat log2.txt

==16154== Memcheck, a memory error detector.

==16154== Copyright © 2002-2007, and GNU GPL'd, by Julian Seward et al.

==16154== Using LibVEX rev 1854, a library for dynamic binary translation.

==16154== Copyright © 2004-2007, and GNU GPL'd, by OpenWorks LLP.

==16154== Using valgrind-3.3.1, a dynamic binary instrumentation framework.

==16154== Copyright © 2000-2007, and GNU GPL'd, by Julian Seward et al.

==16154== For more details, rerun with: -v

==16154==

==16154== My PID = 16154, parent PID = 15998. Prog and args are:

==16154== ./stargazer

==16154== /etc/stargazer/

==16154==

==16154== Thread 11:

==16154== Conditional jump or move depends on uninitialised value(s)

==16154== at 0x42524D9: std::string::string(char const*, std::allocator<char> const&) (in /usr/lib/gcc/i686-pc-linux-gnu/4.2.3/libstdc++.so.6.0.9)

==16154== by 0x4FADEA5: CONFIGPROTO::RecvData(int) (rsconf.cpp:487)

==16154== by 0x4FAE627: CONFIGPROTO::Run(void*) (rsconf.cpp:244)

==16154== by 0x4FA9BC6: STG_CONFIG::Run(void*) (stgconfig.cpp:222)

==16154== by 0x4070046: start_thread (in /lib/libpthread-2.7.so)

==16154== by 0x4153D1D: clone (in /lib/libc-2.7.so)

==16155==

==16155== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 7 from 1)

==16155== malloc/free: in use at exit: 0 bytes in 0 blocks.

==16155== malloc/free: 503 allocs, 503 frees, 11,151 bytes allocated.

==16155== For counts of detected errors, rerun with: -v

==16155== All heap blocks were freed -- no leaks are possible.

==16154==

==16154== ERROR SUMMARY: 6 errors from 1 contexts (suppressed: 77 from 2)

==16154== malloc/free: in use at exit: 9,371 bytes in 61 blocks.

==16154== malloc/free: 2,036,950 allocs, 2,036,889 frees, 381,065,301 bytes allocated.

==16154== For counts of detected errors, rerun with: -v

==16154== searching for pointers to 61 not-freed blocks.

==16154== checked 75,608,492 bytes.

==16154==

==16154== LEAK SUMMARY:

==16154== definitely lost: 7,851 bytes in 50 blocks.

==16154== possibly lost: 1,296 bytes in 9 blocks.

==16154== still reachable: 224 bytes in 2 blocks.

==16154== suppressed: 0 bytes in 0 blocks.

==16154== Rerun with --leak-check=full to see details of leaked memory.

 

В выводе консоли вся стандартная информация. Строки связанные с конфигуратором приведены ниже:

 

rsconf.cpp > 18:29:57 > Connection accepted from 95.135.54.154

rsconf.cpp > 18:29:58 > Connection accepted from 95.79.203.113

rsconf.cpp > 18:30:09 > Connection accepted from 95.132.228.212

rsconf.cpp > 18:30:10 > Connection accepted from 192.168.0.1

configproto.cpp > 18:30:10 > ParseXMLStart

configproto.cpp > 18:30:10 > Start

configproto.cpp > 18:30:10 > Start

configproto.cpp > 18:30:10 > Start

configproto.cpp > 18:30:10 > Start

configproto.cpp > 18:30:10 > ParseXMLStart

configproto.cpp > 18:30:10 > ParseXMLStart

parser.cpp > 18:30:10 > <SetUser result="ok"/>

configproto.cpp > 18:30:10 > currParser == NULL

rsconf.cpp > 18:30:12 > Connection accepted from 78.12.198.120

 

После этого конфигуратор висит или просто не коннектится. Более в логе ничего связанного с конфигуратором не нашел....

[laffytaffy 84]

глюк подтверждаю. От версии конфигуратора или консольного конфигуратора не зависит.

Проявляется:

1. При добавлении нового пользователя.

Пользователь создается, конфигуратор подвисает. В итоге имеем что логин появился, пароль, айпишник и все остальные данные - пустые.

Лечится перезапуском демона старгейзера.

2. Само по себе.

Есть открытый кофигуратор, 1 минуту назад редактировали запись, добавляем денег на счет, конфигуратор подвисает.

После 5ти минутного ожидания получаем Recv header answer error.

Новые копии конфигуратора при конекте говорят connect failed.

 

Щаз соберу в дебаг режиме, попробую там что-то найти.....

 

 

вот-вот супер точно описали...

 

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

[madf 279]

Под valgrind был запущен сам КК, не старгейзер?

Буду смотреть...

 

К стати, а база какая используется?

[Keen 10]

запущен старгейзер, подвисает виндовый конфигуратор. Хотя КК тоже.

Насколько я понимаю, подвисает модуль mod_conf_sg.

Используется файловая база.

Сам старгейзер со всеми остальными модулями работает нормально....

В данный момент опять конфигуратор не конектится. Выдает ошибки connect failed или recv header answer error.

 

localhost sgconfig # netstat -an | grep 5556

tcp 0 0 0.0.0.0:5556 0.0.0.0:* LISTEN

tcp 0 0 194.169.205.1:5556 194.187.131.6:63015 SYN_RECV

tcp 0 0 194.169.205.1:5556 94.244.170.212:1150 SYN_RECV

tcp 0 0 194.169.205.1:5556 212.2.132.44:2107 SYN_RECV

tcp 0 0 194.169.205.1:5556 62.199.112.230:50662 SYN_RECV

tcp 0 0 194.169.205.1:5556 94.19.100.69:1723 SYN_RECV

tcp 0 0 194.169.205.1:5556 95.133.37.239:4428 SYN_RECV

tcp 0 0 194.169.205.1:5556 92.244.120.198:3458 SYN_RECV

tcp 0 0 194.169.205.1:5556 95.132.224.212:62506 SYN_RECV

tcp 0 0 194.169.205.1:5556 78.159.41.238:29795 SYN_RECV

tcp 0 0 194.169.205.1:5556 193.34.92.25:3999 SYN_RECV

tcp 0 0 194.169.205.1:5556 195.98.183.4:9864 SYN_RECV

tcp 0 0 194.169.205.1:5556 94.178.56.205:3766 SYN_RECV

tcp 0 0 194.169.205.1:5556 78.159.48.50:1052 SYN_RECV

tcp 0 0 194.169.205.1:5556 91.124.8.71:4490 SYN_RECV

tcp 0 0 194.169.205.1:5556 80.91.186.58:51185 SYN_RECV

tcp 0 0 194.169.205.1:5556 91.210.250.2:3624 SYN_RECV

tcp 0 0 194.169.205.1:5556 93.185.196.186:41692 ESTABLISHED

tcp 69 0 194.169.205.1:5556 195.46.34.14:2502 CLOSE_WAIT

 

Маленькая закономерность в том, что в выводе netstat'a после подвисания всего 18 строк.

последнии строки лога старгейзера:

rsconf.cpp > 10:15:39 > Connection accepted from 89.252.17.22

rsconf.cpp > 10:15:39 > Connection accepted from 193.111.156.166

rsconf.cpp > 10:15:40 > Connection accepted from 213.160.144.186

rsconf.cpp > 10:15:40 > Connection accepted from 93.84.33.146

rsconf.cpp > 10:15:40 > Connection accepted from 93.185.196.186

 

после этого в логе нет ничего связанного с rsconf.cpp и configproto.cpp

 

З.Ы. Мож кто-то подскажет, как прибить коннекты к конфигуратору из вне?

пробовал iptables -A INPUT -p tcp --dport 5556 -src host ! 192.168.0.0/24 -j DROP - пакеты вроде дропаются, но все равно немерянно коннектов....

[trinux 3]

я так понимаю это столько желающих?

localhost sgconfig # netstat -an | grep 5556

tcp 0 0 0.0.0.0:5556 0.0.0.0:* LISTEN

tcp 0 0 194.169.205.1:5556 194.187.131.6:63015 SYN_RECV

tcp 0 0 194.169.205.1:5556 94.244.170.212:1150 SYN_RECV

tcp 0 0 194.169.205.1:5556 212.2.132.44:2107 SYN_RECV

tcp 0 0 194.169.205.1:5556 62.199.112.230:50662 SYN_RECV

tcp 0 0 194.169.205.1:5556 94.19.100.69:1723 SYN_RECV

tcp 0 0 194.169.205.1:5556 95.133.37.239:4428 SYN_RECV

tcp 0 0 194.169.205.1:5556 92.244.120.198:3458 SYN_RECV

tcp 0 0 194.169.205.1:5556 95.132.224.212:62506 SYN_RECV

tcp 0 0 194.169.205.1:5556 78.159.41.238:29795 SYN_RECV

tcp 0 0 194.169.205.1:5556 193.34.92.25:3999 SYN_RECV

tcp 0 0 194.169.205.1:5556 195.98.183.4:9864 SYN_RECV

tcp 0 0 194.169.205.1:5556 94.178.56.205:3766 SYN_RECV

tcp 0 0 194.169.205.1:5556 78.159.48.50:1052 SYN_RECV

tcp 0 0 194.169.205.1:5556 91.124.8.71:4490 SYN_RECV

tcp 0 0 194.169.205.1:5556 80.91.186.58:51185 SYN_RECV

tcp 0 0 194.169.205.1:5556 91.210.250.2:3624 SYN_RECV

tcp 0 0 194.169.205.1:5556 93.185.196.186:41692 ESTABLISHED

tcp 69 0 194.169.205.1:5556 195.46.34.14:2502 CLOSE_WAIT

 

 

 

 

кому можно:

$IPTABLES -A INPUT -p tcp -s $кому -d $куда --dport 5556 -j ACCEPT

остальным закрыть полностью:

$IPTABLES -A INPUT -p tcp --dport 5556 -j REJECT ????

 

 

дыг у вас вроде не светится порт 5556

[Keen 10]

то что я и думал, но откуда тогда соеденения из вне?

[ZoomZomm 0]

кто-то разобрался с даным багом или нет?

у меня та же картина, при любых изменениях в юзверя вылетает recv header answer error

[Kucher2 122]

У меня юзеры на порту 8888, конфигуратор на 5555. Таких траблов небыло пока. Тьфу-тьфу-тьфу.

Зато был глюк с попыткой послать сообщения через консольный конфигуратор, когда пытаются подключиться более 10-ти юзеров - висло всё наглухо.

madf сказал, что есть такая проблема с СТГ - пришлось мне эту фичу отключить. А жаль.

Гляньте ещё на всякий случай netstat на порт конфигуратора в этот момент.

[madf 279]

кто-то разобрался с даным багом или нет?

у меня та же картина, при любых изменениях в юзверя вылетает recv header answer error

Это у тебя какая-то другая проблема. Можно поподробнее?

 

У меня юзеры на порту 8888, конфигуратор на 5555. Таких траблов небыло пока. Тьфу-тьфу-тьфу.

Зато был глюк с попыткой послать сообщения через консольный конфигуратор, когда пытаются подключиться более 10-ти юзеров - висло всё наглухо.

madf сказал, что есть такая проблема с СТГ - пришлось мне эту фичу отключить. А жаль.

Гляньте ещё на всякий случай netstat на порт конфигуратора в этот момент.

Различные порты тут не при чем. Конфигуратор и авторизатор работают на разных протоколах.

[ZoomZomm 0]

кто-то разобрался с даным багом или нет?

у меня та же картина, при любых изменениях в юзверя вылетает recv header answer error

Это у тебя какая-то другая проблема. Можно поподробнее?

что для подробней надо?

[madf 279]

кто-то разобрался с даным багом или нет?

у меня та же картина, при любых изменениях в юзверя вылетает recv header answer error

Это у тебя какая-то другая проблема. Можно поподробнее?

что для подробней надо?

Для начала:

- версии конфигуратора и старгейзера;

- последовательность действий приводящая к такому эффекту;

- содержимое лога старгейзера в этот момент.

 

Потом может понадобиться отладочная сборка и консольный лог.