Jump to content
Local
XoRe

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

Recommended Posts

При сборке дополнительные ключи указывались?

Share this post


Link to post
Share on other sites

А что gdb пишет при загрузке core dump?

Share this post


Link to post
Share on other sites

а не было корки, я аттачил пид зависшего старгазера, который потом убил по -KILL

дополнительных ключей сборки не было, собирал как обычно:

./build; gmake all; gmake install в каталогах projects/stargazer, projects/sgconf, projects/sgconf_xml

с предварительной очисткой /usr/lib/stg

./build debug не собрался, чего-то не хватало, если будет нужно, то я это сделаю..

пока он еще не падал.

Share this post


Link to post
Share on other sites

А, завис! Так с этого надо и было начинать.

./build debug бы очень помог.

Share this post


Link to post
Share on other sites

Cобрал debug, но нет повода его переинсталлить, тк. stg не падает.

Там в чем весь прикол, как оказалось, когда зависает stg, в процессах висит также незавершившийся скрипт OnConnect,

и если его убить, то stg начинает работать снова.

Расковырял тамошний OnConnect, вроде бы нашел место, где он теоретически мог иногда виснуть, на этапе привязки адресов к макам, переписал сейчас его код, будем наблюдать.

Share this post


Link to post
Share on other sites

   If sufficient space is available in the queue, msgsnd() succeeds immediately.  (The queue capacity is defined by the msg_qbytes field in the associated data structure for the message queue.  During queue cre‐
   ation this field is initialized to MSGMNB bytes, but this limit can be modified using msgctl(2).)  If insufficient space is available in the queue, then the default behavior of  msgsnd()  is  to  block  until
   space becomes available.  If IPC_NOWAIT is specified in msgflg, then the call instead fails with the error EAGAIN

© man msgsnd

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

Share this post


Link to post
Share on other sites

Пожалуй, во избежание подобного, имеет смысл сделать единственную точку взаимодействия с stg-exec в архитектуре, внутри которой будет ring buffer (немного добавит отзывчивости при тормозных скриптах) и срач в лог при 100% заполнении буфера.

Пока можно от такого спасаться запуском двух stg-exec (ExecutersNum = 2) и каким-нибуть внешним мониторингом зависших скриптов.

Share this post


Link to post
Share on other sites

хм, очень интересно..

в скрипте OnConnect виснет вызов sgconf. Первым виснет sgconf, который не дает завершиться скрипту OnConnect, который соответственно вешает stg-exec.

В этом вызове совершенно стандартный set --ud1, который записывает в базу мак адрес клиента, если там его еще нет. Отрабатывает этот вызов

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

После прибивания зависшего sgconf, вся цепочка оживает, причем поле --ud1 у нужного пользователя всегда оказывается обновленным, те. данные

успевают передаться в mod_store перед тем, как sgconf зависнет.

Пока ничего, кроме watchdog по крону, который будет прибивать зависший sgconf, в голову не приходит..

Share this post


Link to post
Share on other sites

cp /usr/lib/stg/mod_conf_sg.so /usr/lib/stg/mod_conf_sg1.so

в конфиге повесте его на отдельный порт

 

<Module conf_sg1>
Port = 4445
</Module>

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

 

-----

у меня вот так

skyprox:/# ls /usr/lib/stg/ | grep mod_conf_sg
mod_conf_sg1.so
mod_conf_sg2.so
mod_conf_sg3.so
mod_conf_sg.so
skyprox:/# cat /etc/stargazer/stargazer.conf | grep conf_sg -A 2
<Module conf_sg>
Port = 4444
</Module>
--
<Module conf_sg1>
Port = 4445
</Module>
--
<Module conf_sg2>
Port = 4446
</Module>
--
<Module conf_sg3>
Port = 4447
</Module>

работа всех ручных скриптов раскидана по разным портам, чтобы не пересеклись

Share this post


Link to post
Share on other sites

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

поехать таким образом.

Share this post


Link to post
Share on other sites

...

в скрипте OnConnect виснет вызов sgconf. Первым виснет sgconf, который не дает завершиться скрипту OnConnect, который соответственно вешает stg-exec.

...

Версия 2.408-rc2? Или 2.407-p1?

Если 2.408-rc2 то хотелось бы получить стектрейс stargazer'а и sgconf в момент зависания.

Share this post


Link to post
Share on other sites

...

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

...

Верно только для 2.407 и более ранних. В 2.408 я, вроде, исправил эту досадную проблему.

Share this post


Link to post
Share on other sites

сейчас работает версия stg 2.408-rc2, версия sgconf 1.08.9

Share this post


Link to post
Share on other sites

сделал так, как посоветовал yKpon, консольный sgconf на кастомном порту начал вешаться практически сразу, при этом штатный mod_conf_sg работал и принимал соединения.

вот трейсы:

http://pastebin.com/8s6PE4Ky - бекрейс sgconf

http://pastebin.com/UE3ak6EF - бектрейс stargazer.

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

Также мне абсолютно непонятен трейс, начиная с 178 строки.

все собрано с ./build debug, теперь мне в консоли где я запускал stargazer валит debug

единственное что забыл сделать - поменять ExecutersNum

 

пока закоментил в OnConnect проблемный вызов sgconf

Share this post


Link to post
Share on other sites

Странные у вас стектрейсы... но не важно. Сколько всего зависших скриптов было в данный момент?

Share this post


Link to post
Share on other sites

один

Upd. раскоментировал вызов sgconf из OnConnect и перезапустил stg с ExecutersNum = 10.

Консольный sgconf на отдельном порту (клон mod_conf_sg) виснуть со старта перестал, зашел в GDB, посмотрел на процесс stargazer - все нити целые, зависших процессов пока нет.

Share this post


Link to post
Share on other sites

Проблема, как я ее вижу, в следующем: при коннекте вызывается OnConnect который пишет в MAC в --ud1 в результате чего должен вызваться OnChange, но OnConnect еще не завершился, т.к. ожидает результатов записи, по этому stg-exec не может обработать OnChange, по этому изменение ud1 происходит не до конца, по этому sgconf не завершается (ожидает ответа), по этому все зависает. Банальный дедлок.ExecutersNum >1 дожно помочь.

Share this post


Link to post
Share on other sites

Интересное и логичное предположение.

Но почему тогда оно не висло сразу и в 100% случаев, а крайне редко и не периодично ?

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

Share this post


Link to post
Share on other sites

Предпложение-то логичное, но не правильное. Размер messge queue в Linux по умолчанию равен 16к. Размер одного сообщения - порядка 1к. Т.е. в очереди должно без блокировки умещаться 16 сообщений и проблема не должна возникать. Почему она все-таки возникает - затрудняюсь сказать.

Share this post


Link to post
Share on other sites

Снова завис старгазер, точнее завис модуль взаимодействия с виндовым конфигуратором,

отдельный его клон - модуль работы с локальным консольным конфигуратором на отдельном порту

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

пришлось убивать все процессы по -KILL.

вот дамп - http://pastebin.com/JwdmdjzZ

как я понял, интересующая нас нитка - Thread 1

Share this post


Link to post
Share on other sites

Снова завис старгазер, точнее завис модуль взаимодействия с виндовым конфигуратором,

отдельный его клон - модуль работы с локальным консольным конфигуратором на отдельном порту

нормально продолжал работу...

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

Share this post


Link to post
Share on other sites

Снова завис старгазер, точнее завис модуль взаимодействия с виндовым конфигуратором,

отдельный его клон - модуль работы с локальным консольным конфигуратором на отдельном порту

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

пришлось убивать все процессы по -KILL.

вот дамп - http://pastebin.com/JwdmdjzZ

как я понял, интересующая нас нитка - Thread 1

Ну увидел там зависания. Хотелось бы еще увидеть динамику: вывод strace по такой нити в течении десятка секунд. Делается просто: strace -p <pid>, где pid - pid нити (не процесса!). В приведенном трейсе pid - это LWP.

Share this post


Link to post
Share on other sites

Снова завис старгазер, точнее завис модуль взаимодействия с виндовым конфигуратором,

отдельный его клон - модуль работы с локальным консольным конфигуратором на отдельном порту

нормально продолжал работу...

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

Давайте не будем мешать в одну кучу зависания в 2.407-p1 и более ранних с зависаниями в 2.408.

Share this post


Link to post
Share on other sites

madf, стоит ли в ближайшем будущем ждать этой функции снятия абонплаты, о которой я описал выше?

Share this post


Link to post
Share on other sites

Сомневаюсь. Это достаточно сложно реализовать, т.к. снятие абонплаты и сброс месячных счетчиков трафика - это два разных процесса, происходящих в разное время (DayFee, DayResetTraff), а доступа к статистике за предыдущие периоды внутри системы нет. Думаю, не раньше 2.409.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

×