Перейти до

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


Рекомендованные сообщения

  • Відповіді 512
  • Створено
  • Остання відповідь

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

Не выбор кодировки а исключительно Unicode. Не понимаю людей которые до сих пор пользуются koi8/cp1251/cp866 и прочими пережитками прошлого.

Допиливаю rc3

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

Posted Images

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

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

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

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

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

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

Ссылка на сообщение
Поделиться на других сайтах
  • 2 weeks later...

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

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

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

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

Ссылка на сообщение
Поделиться на других сайтах

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

Ссылка на сообщение
Поделиться на других сайтах

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

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

Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

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

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

Ссылка на сообщение
Поделиться на других сайтах

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>

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

Ссылка на сообщение
Поделиться на других сайтах

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

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

Ссылка на сообщение
Поделиться на других сайтах

...

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

...

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

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

Ссылка на сообщение
Поделиться на других сайтах

...

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

...

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

Ссылка на сообщение
Поделиться на других сайтах

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

вот трейсы:

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

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

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

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

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

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

 

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

Ссылка на сообщение
Поделиться на других сайтах

один

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

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

Ссылка на сообщение
Поделиться на других сайтах

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

Ссылка на сообщение
Поделиться на других сайтах

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

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

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

Ссылка на сообщение
Поделиться на других сайтах

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

Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

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

Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

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

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

Ссылка на сообщение
Поделиться на других сайтах

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

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

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

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

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

Ссылка на сообщение
Поделиться на других сайтах

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

Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

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

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Вхід

Уже зарегистрированы? Войдите здесь.

Войти сейчас
  • Зараз на сторінці   0 користувачів

    Немає користувачів, що переглядають цю сторінку.


×
×
  • Створити нове...