madf 279 Опубліковано: 2011-11-15 17:10:08 Share Опубліковано: 2011-11-15 17:10:08 При сборке дополнительные ключи указывались? Ссылка на сообщение Поделиться на других сайтах
madf 279 Опубліковано: 2011-11-15 17:23:12 Share Опубліковано: 2011-11-15 17:23:12 А что gdb пишет при загрузке core dump? Ссылка на сообщение Поделиться на других сайтах
Balu75 0 Опубліковано: 2011-11-16 09:25:00 Share Опубліковано: 2011-11-16 09:25:00 а не было корки, я аттачил пид зависшего старгазера, который потом убил по -KILL дополнительных ключей сборки не было, собирал как обычно: ./build; gmake all; gmake install в каталогах projects/stargazer, projects/sgconf, projects/sgconf_xml с предварительной очисткой /usr/lib/stg ./build debug не собрался, чего-то не хватало, если будет нужно, то я это сделаю.. пока он еще не падал. Ссылка на сообщение Поделиться на других сайтах
madf 279 Опубліковано: 2011-11-16 11:59:48 Share Опубліковано: 2011-11-16 11:59:48 А, завис! Так с этого надо и было начинать. ./build debug бы очень помог. Ссылка на сообщение Поделиться на других сайтах
Balu75 0 Опубліковано: 2011-11-24 13:09:33 Share Опубліковано: 2011-11-24 13:09:33 Cобрал debug, но нет повода его переинсталлить, тк. stg не падает. Там в чем весь прикол, как оказалось, когда зависает stg, в процессах висит также незавершившийся скрипт OnConnect, и если его убить, то stg начинает работать снова. Расковырял тамошний OnConnect, вроде бы нашел место, где он теоретически мог иногда виснуть, на этапе привязки адресов к макам, переписал сейчас его код, будем наблюдать. Ссылка на сообщение Поделиться на других сайтах
madf 279 Опубліковано: 2011-11-26 09:39:37 Share Опубліковано: 2011-11-26 09:39:37 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 279 Опубліковано: 2011-11-26 09:44:08 Share Опубліковано: 2011-11-26 09:44:08 Пожалуй, во избежание подобного, имеет смысл сделать единственную точку взаимодействия с stg-exec в архитектуре, внутри которой будет ring buffer (немного добавит отзывчивости при тормозных скриптах) и срач в лог при 100% заполнении буфера. Пока можно от такого спасаться запуском двух stg-exec (ExecutersNum = 2) и каким-нибуть внешним мониторингом зависших скриптов. Ссылка на сообщение Поделиться на других сайтах
Balu75 0 Опубліковано: 2011-11-29 17:53:59 Share Опубліковано: 2011-11-29 17:53:59 хм, очень интересно.. в скрипте OnConnect виснет вызов sgconf. Первым виснет sgconf, который не дает завершиться скрипту OnConnect, который соответственно вешает stg-exec. В этом вызове совершенно стандартный set --ud1, который записывает в базу мак адрес клиента, если там его еще нет. Отрабатывает этот вызов сотни раз совершенно нормально, пока в очередной раз не виснет. После прибивания зависшего sgconf, вся цепочка оживает, причем поле --ud1 у нужного пользователя всегда оказывается обновленным, те. данные успевают передаться в mod_store перед тем, как sgconf зависнет. Пока ничего, кроме watchdog по крону, который будет прибивать зависший sgconf, в голову не приходит.. Ссылка на сообщение Поделиться на других сайтах
yKpon 8 Опубліковано: 2011-11-30 04:21:44 Share Опубліковано: 2011-11-30 04:21:44 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 0 Опубліковано: 2011-11-30 09:08:11 Share Опубліковано: 2011-11-30 09:08:11 Ух, оччень похоже, огромное спасибо, сконфигурил подобным образом, завтра утром перестрелим stg и попробуем поехать таким образом. Ссылка на сообщение Поделиться на других сайтах
madf 279 Опубліковано: 2011-11-30 09:17:18 Share Опубліковано: 2011-11-30 09:17:18 ... в скрипте OnConnect виснет вызов sgconf. Первым виснет sgconf, который не дает завершиться скрипту OnConnect, который соответственно вешает stg-exec. ... Версия 2.408-rc2? Или 2.407-p1? Если 2.408-rc2 то хотелось бы получить стектрейс stargazer'а и sgconf в момент зависания. Ссылка на сообщение Поделиться на других сайтах
madf 279 Опубліковано: 2011-11-30 09:18:52 Share Опубліковано: 2011-11-30 09:18:52 ... на этот порт и обращайтесь в OnConnect, возможно запускали конфигуратор и одновременно пересеклись с консольным sgconf, стг уходит в нирвану в таких случая - проверено ... Верно только для 2.407 и более ранних. В 2.408 я, вроде, исправил эту досадную проблему. Ссылка на сообщение Поделиться на других сайтах
Balu75 0 Опубліковано: 2011-11-30 09:26:10 Share Опубліковано: 2011-11-30 09:26:10 сейчас работает версия stg 2.408-rc2, версия sgconf 1.08.9 Ссылка на сообщение Поделиться на других сайтах
Balu75 0 Опубліковано: 2011-11-30 10:20:42 Share Опубліковано: 2011-11-30 10:20:42 сделал так, как посоветовал 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 279 Опубліковано: 2011-11-30 10:51:48 Share Опубліковано: 2011-11-30 10:51:48 Странные у вас стектрейсы... но не важно. Сколько всего зависших скриптов было в данный момент? Ссылка на сообщение Поделиться на других сайтах
Balu75 0 Опубліковано: 2011-11-30 10:52:16 Share Опубліковано: 2011-11-30 10:52:16 один Upd. раскоментировал вызов sgconf из OnConnect и перезапустил stg с ExecutersNum = 10. Консольный sgconf на отдельном порту (клон mod_conf_sg) виснуть со старта перестал, зашел в GDB, посмотрел на процесс stargazer - все нити целые, зависших процессов пока нет. Ссылка на сообщение Поделиться на других сайтах
madf 279 Опубліковано: 2011-11-30 13:29:47 Share Опубліковано: 2011-11-30 13:29:47 Проблема, как я ее вижу, в следующем: при коннекте вызывается OnConnect который пишет в MAC в --ud1 в результате чего должен вызваться OnChange, но OnConnect еще не завершился, т.к. ожидает результатов записи, по этому stg-exec не может обработать OnChange, по этому изменение ud1 происходит не до конца, по этому sgconf не завершается (ожидает ответа), по этому все зависает. Банальный дедлок.ExecutersNum >1 дожно помочь. Ссылка на сообщение Поделиться на других сайтах
Balu75 0 Опубліковано: 2011-11-30 14:05:19 Share Опубліковано: 2011-11-30 14:05:19 Интересное и логичное предположение. Но почему тогда оно не висло сразу и в 100% случаев, а крайне редко и не периодично ? В своих тестах я сносил маки в базе всем тем клиентам, у которых установлен флаг AlwaysOnline, потом при рестарте stg всем им апдейтил их маки при подключении, и ничего не висло, а потом в какой-то момент хлоп и все. Ссылка на сообщение Поделиться на других сайтах
madf 279 Опубліковано: 2011-11-30 14:10:51 Share Опубліковано: 2011-11-30 14:10:51 Предпложение-то логичное, но не правильное. Размер messge queue в Linux по умолчанию равен 16к. Размер одного сообщения - порядка 1к. Т.е. в очереди должно без блокировки умещаться 16 сообщений и проблема не должна возникать. Почему она все-таки возникает - затрудняюсь сказать. Ссылка на сообщение Поделиться на других сайтах
Balu75 0 Опубліковано: 2011-12-06 15:05:47 Share Опубліковано: 2011-12-06 15:05:47 Снова завис старгазер, точнее завис модуль взаимодействия с виндовым конфигуратором, отдельный его клон - модуль работы с локальным консольным конфигуратором на отдельном порту нормально продолжал работу, также нормально работал модуль mod_ia и пользователи могли коннетиться. пришлось убивать все процессы по -KILL. вот дамп - http://pastebin.com/JwdmdjzZ как я понял, интересующая нас нитка - Thread 1 Ссылка на сообщение Поделиться на других сайтах
yKpon 8 Опубліковано: 2011-12-07 04:20:21 Share Опубліковано: 2011-12-07 04:20:21 Снова завис старгазер, точнее завис модуль взаимодействия с виндовым конфигуратором, отдельный его клон - модуль работы с локальным консольным конфигуратором на отдельном порту нормально продолжал работу... подтверждаю, у меня тоже такое было, зависал порт по которому управлялось через виндовый сгконф Ссылка на сообщение Поделиться на других сайтах
madf 279 Опубліковано: 2011-12-07 10:59:51 Share Опубліковано: 2011-12-07 10:59:51 Снова завис старгазер, точнее завис модуль взаимодействия с виндовым конфигуратором, отдельный его клон - модуль работы с локальным консольным конфигуратором на отдельном порту нормально продолжал работу, также нормально работал модуль mod_ia и пользователи могли коннетиться. пришлось убивать все процессы по -KILL. вот дамп - http://pastebin.com/JwdmdjzZ как я понял, интересующая нас нитка - Thread 1 Ну увидел там зависания. Хотелось бы еще увидеть динамику: вывод strace по такой нити в течении десятка секунд. Делается просто: strace -p <pid>, где pid - pid нити (не процесса!). В приведенном трейсе pid - это LWP. Ссылка на сообщение Поделиться на других сайтах
madf 279 Опубліковано: 2011-12-07 11:01:03 Share Опубліковано: 2011-12-07 11:01:03 Снова завис старгазер, точнее завис модуль взаимодействия с виндовым конфигуратором, отдельный его клон - модуль работы с локальным консольным конфигуратором на отдельном порту нормально продолжал работу... подтверждаю, у меня тоже такое было, зависал порт по которому управлялось через виндовый сгконф Давайте не будем мешать в одну кучу зависания в 2.407-p1 и более ранних с зависаниями в 2.408. Ссылка на сообщение Поделиться на других сайтах
yKpon 8 Опубліковано: 2011-12-09 12:38:58 Share Опубліковано: 2011-12-09 12:38:58 madf, стоит ли в ближайшем будущем ждать этой функции снятия абонплаты, о которой я описал выше? Ссылка на сообщение Поделиться на других сайтах
madf 279 Опубліковано: 2011-12-09 12:49:56 Share Опубліковано: 2011-12-09 12:49:56 Сомневаюсь. Это достаточно сложно реализовать, т.к. снятие абонплаты и сброс месячных счетчиков трафика - это два разных процесса, происходящих в разное время (DayFee, DayResetTraff), а доступа к статистике за предыдущие периоды внутри системы нет. Думаю, не раньше 2.409. Ссылка на сообщение Поделиться на других сайтах
Рекомендованные сообщения
Создайте аккаунт или войдите в него для комментирования
Вы должны быть пользователем, чтобы оставить комментарий
Создать аккаунт
Зарегистрируйтесь для получения аккаунта. Это просто!
Зарегистрировать аккаунтВхід
Уже зарегистрированы? Войдите здесь.
Войти сейчас