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

[madf]

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

[madf]

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

[Balu75]

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

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

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

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

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

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

[madf]

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

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

[Balu75]

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

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

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

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

[madf]

   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, он перестал принимать сообщения, очередь переполнилась, заблокировалась отсылка сообщений что привело к последовательной блокировке всех нитей.

[madf]

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

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

[Balu75]

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

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

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

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

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

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

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

[yKpon]

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>

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

[Balu75]

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

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

[madf]

...

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

...

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

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

[madf]

...

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

...

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

[Balu75]

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

[Balu75]

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

вот трейсы:

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

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

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

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

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

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

 

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

[madf]

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

[Balu75]

один

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

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

[madf]

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

[Balu75]

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

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

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

[madf]

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

[Balu75]

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

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

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

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

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

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

[yKpon]

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

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

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

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

[madf]

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

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

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

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

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

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

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

[madf]

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

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

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

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

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

[yKpon]

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

[madf]

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