Balu75

Ще актуально ? Цікавить Edge-Core ECS5520-18X

Up. В наличии одна /21 (восемь /24 одним блоком) и одна /24 отдельно. Цена см. выше. Срок аренды от полугода. Обоснованный торг вполне уместен. Спамеров, как и прежде, просьба не беспокоиться.

Можно ли уточнить, по какой причине снеcли мой топик. Разобрались, спасибо.

Добрый день ! Неспешно сдадим в аренду несколько сетей IPv4. На сегодняшний день есть /21 (от 1500грн за 256 адресов) и две /24, RIPE region. Срок аренды от полугода, цена от 1500 грн/месяц за /24. Оптом и на большой срок (до 2 лет) можем дать небольшую скидку. Сети полностью чистые, предпочтение отдадим операторам связи, спамерам просьба не беспокоиться. Связь через ЛС.

Ну увидел там зависания. Хотелось бы еще увидеть динамику: вывод strace по такой нити в течении десятка секунд. Делается просто: strace -p <pid>, где pid - pid нити (не процесса!). В приведенном трейсе pid - это LWP. пробовал по LWP - strace: open("/proc/...", ...): No such file or directory trouble opening proc file пробовал по пиду процесса - Process 37805 attached - interrupt to quit pread: Device busy syscall trouble ни так ни так не получается подключить к процессу strace

Снова завис старгазер, точнее завис модуль взаимодействия с виндовым конфигуратором, отдельный его клон - модуль работы с локальным консольным конфигуратором на отдельном порту нормально продолжал работу, также нормально работал модуль mod_ia и пользователи могли коннетиться. пришлось убивать все процессы по -KILL. вот дамп - http://pastebin.com/JwdmdjzZ как я понял, интересующая нас нитка - Thread 1

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

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

сделал так, как посоветовал yKpon, консольный sgconf на кастомном порту начал вешаться практически сразу, при этом штатный mod_conf_sg работал и принимал соединения. вот трейсы: http://pastebin.com/8s6PE4Ky - бекрейс sgconf http://pastebin.com/UE3ak6EF - бектрейс stargazer. По бектрейсу stg вроде бы получается, что нужная нам зависшая нитка - третья. Также мне абсолютно непонятен трейс, начиная с 178 строки. все собрано с ./build debug, теперь мне в консоли где я запускал stargazer валит debug единственное что забыл сделать - поменять ExecutersNum пока закоментил в OnConnect проблем

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

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

хм, очень интересно.. в скрипте OnConnect виснет вызов sgconf. Первым виснет sgconf, который не дает завершиться скрипту OnConnect, который соответственно вешает stg-exec. В этом вызове совершенно стандартный set --ud1, который записывает в базу мак адрес клиента, если там его еще нет. Отрабатывает этот вызов сотни раз совершенно нормально, пока в очередной раз не виснет. После прибивания зависшего sgconf, вся цепочка оживает, причем поле --ud1 у нужного пользователя всегда оказывается обновленным, те. данные успевают передаться в mod_store перед тем, как sgconf зависнет. Пока ничего, кр

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

Подскажите пожалуйста, каким образом с помощью sgconf можно очистить поле Userdata (--ud) ? При попытке скормить ему пустой символ выдает ошибку sgconf: option `--ud1' requires an argument С помощью конфигуратора такое сделать можно, но если мне нужно сделать это скриптом для нескольких сотен пользователей ?

а не было корки, я аттачил пид зависшего старгазера, который потом убил по -KILL дополнительных ключей сборки не было, собирал как обычно: ./build; gmake all; gmake install в каталогах projects/stargazer, projects/sgconf, projects/sgconf_xml с предварительной очисткой /usr/lib/stg ./build debug не собрался, чего-то не хватало, если будет нужно, то я это сделаю.. пока он еще не падал.

нет, никаких патчей на код не было, мне самому непонятен этот дамп.

Да нет, с железом там все в порядке, оно совсем новое, и выдержало стрестесты, после этого сервер даже не перегружался, его аптайм уже почти месяц, старгазер просто перестрелили и поехали дальше. Пока падать перестал.

Доброго времени суток 2.408-rc2, простоял больше 2х недель, и вот снова начал падать, уже 2-й раз за 2 суток http://pastebin.com/SXy4996C какой-то кривой дамп с corrupt stack, это так и должно быть ?

Прошу прощения за задержку с ответом, но до сегодняшнего дня выкладывать было нечего, 2.407 не падал. После общения с манагерами этой домосети выяснилось, что они научились прогнозировать его падения, в зависимости от своих действий в конфигураторе, те. например после заведения(изменения) юзера в определенном тарифе, и(или) с определенным набором опций, конфигуратор зависал, и вместе с ним зависал старгазер, причем последний зависал намертво и попытки подключиться к нему уже ни к чему уже не приводили. Причем завести юзера в другом тарифе и потом переключить на этот проблемный было вполне

да нет, это очень врядли, во время инсталла они затираются новыми версиями, в любом случае теперь перед инсталлом я обязательно сделаю rm -f /usr/lib/stg/* пока жду, что оно упадет, пока не падает, 2.407-p1 падал где-то раз в сутки, сейчас крутится 2.407

1. я собирал и ставил projects/stargazer, projects/sgconf, projects/sgconf_xml, в соответствии с инструкцией, остальное мною не используется. за последние несколько дней эту операцию я производил уже около десятка раз с разными версиями, всякий раз по крайней мере бинарники заменялись новыми версиями, насчет библиотек я не уверен на 100%, но сейчас все .so библиотеки от 2.407, а все .a - от 2.408-rc2 2. как только оно упадет, я соберу данные gdb c 2.407 и с 2.408 3. всего 728 юзеров, с always online - 270.

Встречный вопрос: когда багрепорты по 2.408-rc2? ну как минимум зависания авторизатора (конфигуратора ?) с "recv header answer error" остались, причем еще более усугубились и теперь старгазер падает уже через несколько секунд после старта, на этапе обработки always online юзеров

2011-10-19 13:31:43 -- Stg v. 2.407

вытянул 2.408-rc2 и сегодня после очередного падения сегодня в срочном порядке поставил его. Итог: он даже не стартует полностью, виснет где-то в процессе авторизации пользователей с галочкой 'Always Online' Конфигуратор выдает ту же ошибку "Recv header answer error", авторизатор висит, у юзеров inetaccess горит красным. 2011-10-19 13:20:04 -- Stg v. 2.408-rc1 2011-10-19 13:20:04 -- Message queue created successfully. msgKey=5555 msgID=720896 2011-10-19 13:20:04 -- Timer thread started successfully. 2011-10-19 13:20:04 -- Storage plugin: mysql_store v.0.67. Loading successfull. 2011-10-

FreeBSD 8.2-p2, установлен Stargazer stg-2.407-p1. Периодически в конфигураторе выскакивает сообщение "Recv header answer error", а у пользователей inetaccess загорается красным и не реконнектится. Файлы монитора продолжают писаться. При попытке зайти телнетом на config порт соединение сбрасывается. В лог ничего военного не пишет. Что можно с этим сделать и какая статистика необходима по проблеме ? 2011-10-18 16:28:09 -- Stg v. 2.407-p1 2011-10-18 16:28:09 -- Message queue created successfully. msgKey=5555 msgID=524288 2011-10-18 16:28:09 -- Timer thread started successfully. 2011-1