madf

А, ну да, - фря, tcsh... Там через setenv. Через gcc тоже должно работать, глявное правильные пути указать.

Во фряхе ж шланг, вроде, по дефолту? В любом случае у вас там в системе какая-то лажа. Но можно явно указать: CC=/usr/bin/clang CXX=/usr/bin/clang++ ./build CC=/usr/bin/clang CXX=/usr/bin/clang++ gmake Ну или gcc48/g++48 вместо clang/clang++.

Как-бы намекает.

gmake clean gmake

Здается мне что вы брешете. Дело, конечно, давнее, но stg никогда не менял логику отключения абонентов. Что Вы, сударь, здесь же мы все джентльмены, я не могу себе такого позволить Мне это точно не приснилось, я минимум пол года пользовался старой версией, и там было именно так. Может это была не 2.406 а еще старше, может еще что-то поменялось при обновлении (хотя я конфиги и скрипты оставил старые) - не знаю, но факт остается, раньше при баланс = 0 инета не было, и мне не приходилось писать в кредите -1. Будет время, не поленюсь, поставлю на виртуалке старый стг и перепроверю... ..

Здается мне что вы брешете. Дело, конечно, давнее, но stg никогда не менял логику отключения абонентов.

А, так чего ж тут непонятного-то. Мускул остановился до того как остановился Старгейзер.

Та это я ритуальную фразу произношу при проблемах с MySQL. Разберитесь что там у вас с СУБД происходит.

И что только люди не делают чтобы не использовать нормальные СУБД...

Вечно.

Фігню пишете, шановний 0 — знімає незалежно від того скільки у абонента грошей на рахунку; 1 — знімає тільки коли баланс додатній (абонент може зайти в „мінус“, але не більше ніж на величину АП); 2 — знімає тільки тоді коли грошей на рахунку достатньо для зняття АП (абонент ніколи не заходить у „мінус“).

Могу вам посочувствовать.

Бесперебойник сам часто причина пропадания питания. Кроме того от других причин повреждения ФС это не защитит, как хардовых, от которых сервер виснет, типа SATA кабель от вибрации стал отходить, перегрев и т.д., так и софтовых, типа глюков в драйверах, ядре и т.д. Так же бесперебойник не защитит от прямого попадания ядерного снаряда, потопа в серверной, мирового финансового кризиса и вируса лихорадки Эбола. И что? На то и бекапы.

Делайте софт-рейд + бесперебойник + офф-сайт бекапы и не парьтесь. Не хочу терять файлы, вроде ничего такого то и не будет, просто потом восстановить все это ужас Рейд защитит от проблем с винтами, тот факт что он "софт-" защитит от проблем с контроллером. Бесперебойник защитит от поврежения ФС при пропадании питания (естественно нужно настроить правильно сервер для отслеживания состояния бесперебойника). Бекапы защищают от случайного удаления, тот факт что они "оффсайт-" защищает от пожара в серверной, изъятия серверов или носителей органами и прочих нештатных ситуаций. Что еще

Делайте софт-рейд + бесперебойник + офф-сайт бекапы и не парьтесь.

Вынести раздачу адресов в отдельный сервис или это слишком сложно для асмодеусов? Задача вообще-то совсем не для СУБД и использовать СУБД в качестве планировщика ресурсов - тот еще маразм. Для чего только БД не используют... У меня на работе, в одной финансовой конторе, БД используется для IPC. И ничего, никто не жалуется. Но я вообще писал не про использование. Меня больше удивило что кто-то жалуется что запросов много.

Напомнило: Возил мужик из Чернигова картошку одним ведром на жигулях, и решил оптимизировать работу покупкой суперкара но с тем же ведром. Если уж сравнивать с ведром картошки то скорее так: возил мужик из Чернигова ведро картошки на жигулях, а когда попросили его привезти два ведра - жаловаться начал, что два это много, вдруг заводиться перестанет. И вообще машина придумана не для перевозки грузов, для нее есть задачи поважнее.

Да ну? А разве это не задача базы - слушать вопросы и отвечать на них? Чем это ей еще заниматься? Чем меньше запросов к базе, тем меньше шансов, что база станет узким местом. "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil" И даже если вдруг оказалось что база стала узким местом - сперва лучше оптимизировать саму базу. Дедлоки или есть (что фатально плохо), или их нет (что хорошо). Раз вы говорите о вероятности появления дедлоков, значит они есть и ваша архитектура - говно. Простите, но я не разрабатывал архи

Да ну? А разве это не задача базы - слушать вопросы и отвечать на них? Чем это ей еще заниматься? Дедлоки или есть (что фатально плохо), или их нет (что хорошо). Раз вы говорите о вероятности появления дедлоков, значит они есть и ваша архитектура - говно.

Можно без sudo. Без install, просто make. И можно без sudo. Библиотеки можно не копировать, cp ../../lib не нужно. sudo gdb /usr/sbin/stargazerПосле этой команды откроется консоль gdb. Там надо выполнить:r /etc/stargazer После падения делаем thread apply all bt и выхлоп мне (сюда или на почту faust@stg.dp.ua).

Да, вместо install-bin нужно руками раскидать: stargazer в /usr/sbin/stargazer, .so-файлы в /usr/lib/stg/

и Немного вы меня не поняли. Я имею ввиду, что при более 2к клиентов стоит задумываться о переходе на другие, коммерческие, более грамотные продукты. Тут вам и рост и стабильность (Ну опять же, совокупность многих факторов). ... Вы по профессии, случайно, не рекламщик?

Если активных клиентов менее 2000, то Abills, mikbill, ubilling. Если вы уже более серьёзно развиваете предприятие и хотите безопасно обновляться, идти в ногу со временем, то уж рассмотрите варианты Гидра, Felix2 может быть карбон и expertbilling. Для региональных операторов связи, присутствуют очень дорогие, но очень надёжные решения, есть ли смысл их здесь упоминать? Откуда ограничение в 2к для ubilling?

Значит надо собирать в отладочном режиме и запускать из-под gdb.

Что последнее в логе?