madf

Можно узнать подробности? Особенно зачем понадобилось останавливать Stg?

Лампы на сетевушке прогреваются, вестимо...

Нет. Любая СУБД требует ухода и присмотра. А особенно PostgreSQL. Да достаточно уже хотя бы того что в стандартной поставке она не рассчитана на сколько-нибуть большие объемы данных и сколько-нибуть существенную нагрузку. Об этом сами авторы пишут.

Потому что эта гадость попадёт в грунтовые воды и со временем к вам на стол. И дай Бог Вам никогда не узнать, к чему это приведёт. Современная атомная энергетика - это атомная война против наших детей. Cолнце, ветер и вода - наши лучшие друзья С какой радости грунтовые воды туда попадут если они выше находятся, а шахта засыпана? Кроме того, урановую руду-то добывают, и ничего. Про грунтовые воды никто не парится.

На официальном сайте есть контакты и расценки.

... переработка и хранение радиоактивных отходов то нихрена не экологичная получается ядерная энергетика. А если учесть что период полураспада некоторых трансуранов составляет 5 тысяч лет, то хранить это дерьмо придется сотню тысяч лет. Современная ядерная энергетика основаная на уран-плутониевом цикле в реакторах на тепловых нейтронах это скорее побочный эффект технологии наработки оружейного плутония. Современные АЭС вырабатывают не столько электроэнергии сколько гемороя на ж#пу нашим потомкам. Единственныая экологическая чистота АЭС это то что она не производит парниковых газов. Все, на э

Первое что приходит в голову - выставить ExecutersNum в 2 или больше и посмотреть как это повлияет на ситуацию.

А можно получить стектрейс на момент зависания? Собрать в отладочном режиме (build debug), раскидать бинарники вручную (stargazer в /usr/sbin и файлы с расширением .so из modules в /usr/lib/stg). В момент зависания выполнить следующую последовательность действий: Посмотреть PID Stargazer'а (/var/run/stargazer.pid или через ps). gdb /usr/sbin/stargazer (gdb) attach <pid> (gdb) Ctrl+C (gdb) thread apply all bt (gdb) detach (gdb) quit Выхлоп после thread apply all bt отправить мне на почту (faust@stg.dp.ua) или прислать ссылку на pastebin.com. Еще интересно что указано в Execute

Файл user_impl.cpp (user.cpp для 2.407 и более старых). Метод IsInetable. Вот в этих строках: if (settings->GetShowFeeInCash() || tariff == NULL) { return (cash >= -credit); } return (cash - tariff->GetFee() >= -credit); заменить >= на > и готовиться к сюрпризам.

Ну, на то тон и git чтоб не собираться периодически Впрочем, посмотрю. Второй раз ошибку не пишет потому что мусор в deps. Если сделать make clean то снова начнет писать.

Ну там вроде как в условии было сказано - зарезать по портам. Вообще хорошая тема, не знаю почему мало кто такое делает. Ну понятно, нагрузка на проц и т.д., но все же...

Ну, вроде, все в порядке, никаких "лишних" OnConnect не наблюдается.

Понимаете, тяжело разобраться в чем проблема когда с одной стороны у вас может быть не рабочий файрвол, а с другой - возможно, где-то ошибки в логике Stargazer или UBilling. Вот например, вы утверждаете что при отключении пользователя для него вызывается OnDisconnect а потом сразу-же OnConnect. Давайте, для начала, разберемся с этой проблемой, а потом уже полезем файрвол изучать. Начнем с простого - как вы отключаете пользователя? И, желательно, сразу приводить логи - как логи скриптов так и логи самого Stargazer. А то мы тычемся как слепые котята и строим предположения на астральных догадк

Ві же говорили что у вас все работало и наоборот не отключало?

Похоже что через Гиганет.

а в чем ? Где-то логика хромает... Или вы, например, отключаете не через AO или "заморозку" и потом делаете reset.

Я практически уверен что вопрос не в скриптах.

Однозначно. Поэтому по-умолчанию пользователя стоит гасить не "отключенностью" а ВсегдаОнлайном или Морозильником, как рекомендовалось раньше. Ресеты зовутся для практически по каждому чиху, для надежности сохранения актуальности пользовательского состояния. Но вот видишь, у товарища не работает. Сломался твой морозильник, наверное

Скрутки - наше все!

Наверное, причина в этом.

В лог-файле Это понятно, вы об этом еще в первом посте написали. Кто пишет этот лог и что за информация в нем?

А как определили что после OnDisconnect вызвался OnConnect?

Посмотреть еще /var/log/stargazer.log и лог юзера. Но последний в базе, по этому его смотреть не очень удобно.

Не, с парсингом вообще зачотно получилось. Ну понятно http - там текстовый протокол. Но TCP и IP же бинарны! Что там можно разбирать синтаксически?! Про коммандную строку, к стати, тоже понятно. Сейчас линуксоидов много стало, да вот компилятор от IDE мало кто отличить может. И ОС от DE. Так что про коммандную строку все верно. А так как обычно, общие слова.

условно "без проблем", и то лишь при условии что роутер юзается для раздачи одноглазиков/контактиков на пару машин, с ежедневным отключением на ночь... При длительном аптайме или под суровыми торрентами мыльнички на стоковой прошивке весьма занятно таращит. Плюсану. Даже не при длительном. Малейшая нагрузка - и висяк.