madf

Вобще похоже на анекдот id к пользователю не привязан.

Стабильная версия на сайте stg.dp.ua. А почему не переносит? Что говорит?

Ну опции RemoveBak и ReadBak модуля store_files никто не отменял. Хотя в определенных случаях и они могут слажать. Никак не доходят руки сделать по нормальному. К стати, каким бы троллем не был vop, но по этому вопросу он совершенно прав. По поводу релиза. У вас есть возможность ускорить его. Людей как всегда не хватает. Так что если есть опыт в программировании - можно подключиться к разработке sgconf_xml погляжу. Но думаю что после релиза он будет больше не нужен

Частично

Не судите строго... видимо я до конца не понимаю что где смотреть. смотрю свойства таблицы charset set cp1251 на сколько я понимаю конвертер переносит данные в базу при помощи стандартного клиента установленого в системе. в качестве просмоторшика я пользуюсь менеджером но какаую бы я не ставил в не кодировку все равно получаю кракозябры. Кстати при помощи стандартного клиента системы тот же ефект. Я так понимаю что конвертер создает таблицы сам, соответсвенно и задает кодировку таблицы но тогда перенося данные из кои8 он должен был их переконвертировать в ср1251. И второй вопрос: конфигур

не з днепропетровска Ха! В одном городе живем

Конвертор переносит базу используя существующие плагины. Клиент не используется. Внутри самого Stargazer'а данные содержатся в кодировке koi8, кроме текстов сообщений пользователям. Сообщения хранятся в кодировке CP1251. Модуль MySQL сам создает нужные таблицы. При этом кодировка явно не указывается, по этому используется та которая установлена для базы. При коннекте к базе не указывается и клиентская кодировка, по этому используется та-же, что и при создании. Т.е. CP1251. При этом туда заносятся данные в кодировке KOI8. Естественно при просмотре получаются кракозябры. Тексты сообщений вы

Проще выложить текущий срез исходников. Если надо - могу заслать на почту.

О такой проблеме известно и она уже решена. Ждите релиза.

Не совпадает кодировка базы, client encoding и в том месте где ты просматриваешь таблицы. Попробуй все поставить в koi8-r. Нет проблемма не в client encoding покрайней мере при просмотре. так как он возникает уже при переносе. может кто знает как с этим бороться повторюсь: но что интересно что таблица messages тоже имеет руский текст, а перенеслась нормально А я не только про client encoding написал. Там минимум 3 места где кодировка задается. Короче так: - внутренняя кодировка Stargazer KOI8; - сообщения хранятся в CP1251. Дальше смотри какая у тебя кодировка базы, clie

Версия, как я вижу, не релизная... Случайно не в отладочном режиме собранная?

Странно как-то... А что в этот момент в /var/log/stargazer.log, /var/log/messages, dmesg?

Не хочет коннектиться - это как?

Проблемы с сетью, например.

Ну вот он как-бы пытается принять заголовок пакета от конфигуратора и никак не может его принять.

А еще можно собрать с отладочной информацией и когда он перестанет коннектится подцепиться к нему gdb: $ gdb /path/to/stargazer (gdb) attach pid-of-stargazer и после этого посмотреть трассы стека по всем потокам: (gdb) thread apply all bt Можно даже выслать мне их на почту: faust@stg.dp.ua

Ну можно попытаться в тупую - наставить журналирования в плагин и посмотреть в каком месте оно затыкается. А потом определить причину.

если не хотите свое сделать, может быть добавите в релиз разработку человека ? Думаю не один из пользователей стг не откажется от данной функии... Я не говорил что не хочу своего делать. Просто на все не хватает рук. А вот добавлять в релиз костыли я точно не буду. Уж извините.

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

Жесть

Каким макаром тарифный план определяется?

В авторизаторі? Думаю нічого. Буду просувати qia.

Мой "хинт" перестает работать, когда начинается новый месяц . Вот другой фикс в конфигураторе, вроде как 3 месяца без глюков http://depositfiles.com/ru/files/i70bbmh2g, при этом в сервере можно всё вернуть обратно. Ну там на самом деле проблема на стороне плагина. Точнее даже на стороне самого Stargazer'а Может это и проблема, но у меня получилось, что не проблема, а на оборот. Использовал эту фичу с обновлением по другому, теперь любые изменения аккаунтов в таблице обновлятся сразу после изменения, нет необходимости давить кнопку refresh. Очень кстати удобно. Ну это тоже правил

Такое могло случиться если Stargazer был собран через build/make а для sgconf был просто вызван make. При этом новая версия libsrvconf.so просто не собралась и, естественно, не установилась. Stargazer был собран через 1. > ./build 2. > make install sgconf был собран через ./build библиотека скомпилилась кстати, но не была обновлена. я ее просто скопировал взамен старой. теперь проблем нет. Ну да, если запускается из каталога сборки нужно указывать LD_LIBRARY_PATH=../../lib чтобы он брал библиотеки не из /usr/lib

и сколько стартует СТГ на ней времени? у меня получилось: 2010-03-06 04:03:47 -- Storage plugin: postgresql_store v.1.2. Loading successfull. 2010-03-06 04:05:48 -- Users started successfully. после 10ти дней работы, вообще один процесс postgres залочил таблицу stat-ов. попытался остановить СТГ в логах : ну убил все, слил дамп, пересоздал базу с нуля. Время старта плагина уменьшилось до 2х сек. вот теперь сижу и думаю, как будет корректней проапгрейдиться? А то такими глюками, как-то в "продакшн" не хочется лезть... и Вообще "оно" себя чувствует под нагрузкой? Сколько стартуе