Глюк при переходе на новый рассчетный период (март).

Технические вопросы по UTM 5.0
Ответить
Аватара пользователя
Ata-man
Сообщения: 427
Зарегистрирован: Пт янв 21, 2005 10:04
Откуда: Екатеринбург

Глюк при переходе на новый рассчетный период (март).

Сообщение Ata-man »

UTM 5.2.1-006upd7, FBSD 6.0

Сегодня при переходе на новый рассч. период биллинг сглючил: создал новый рассч. период с датой начала и конца = 28.02.10 23:59:59. В итоге он пытался перевести на него клиентов, но не мог и создавал новый рассчетный период с новым ID, но с той же датой начала и конца. Пока обнаружил проблему (в 0:17), он успел уже сгенерить пятый такой период. Исправил руками дату окончания на правильную (31.03.10 23:59:59) - и только тогда UTM стал переводить клиентов на новые тарифы, выставлять счета и т.п. Проверил по отчетам, вроде все платежи за услуги снялись верно, но возможно в будущем вылезут проблемы, особенно с пересчетом абон. платы :( .

Весь main.log лог был забит следующими записями:

Код: Выделить всё

ERROR : Mar 01:16:29 DBAInternalError: big classif gluk, about gluk i->first: 0, downloaded: 0
Что было перед этими сообщениями - неизвестно, т.к. за 17 минут успело перезаписаться 700Мб логов.

UPD.
Нет, не все логи перезаписались, вот подозрительная запись в debug.log:

Код: Выделить всё

?Debug &#58; Feb 28 23&#58;59&#58;59 UTM5 DBA&#58; __fill_charge_info&#58; accounting period <3445> end_time <1267383599> smaller than current time <1267383599>, setting to <1267383598>
- Странно, но он считает что 1267383599 меньше, чем 1267383599 :)

banec
Сообщения: 269
Зарегистрирован: Вт сен 11, 2007 09:06

Сообщение banec »

+1
такой же глюк!!! :x
ос дебиан
в долги вроде не загнал никого

mikkey finn
Сообщения: 1612
Зарегистрирован: Пт ноя 10, 2006 15:23

Сообщение mikkey finn »

вроде пронесло, руками ничего не делал дополнительно

Аватара пользователя
TiRider
Сообщения: 568
Зарегистрирован: Сб июн 07, 2008 12:43

Сообщение TiRider »

У меня вообще хренотень... в верификаторе

Код: Выделить всё

-- ERROR account 485 not blocked, but where is entry with id 3140 in blocks_info
-- SQL DESC delete entry in blocks_info
UPDATE blocks_info SET is_deleted=1 WHERE account_id='485' AND start_date<='1265496134' AND expire_date>='1265496134' AND is_deleted=0;
Это вообще чего?

dwemer
Сообщения: 276
Зарегистрирован: Чт янв 25, 2007 05:59

Сообщение dwemer »

TiRider писал(а):У меня вообще хренотень... в верификаторе

Код: Выделить всё

-- ERROR account 485 not blocked, but where is entry with id 3140 in blocks_info
-- SQL DESC delete entry in blocks_info
UPDATE blocks_info SET is_deleted=1 WHERE account_id='485' AND start_date<='1265496134' AND expire_date>='1265496134' AND is_deleted=0;
Это вообще чего?
Это нарушение логики )
Можно выполнить предлагаемые запросы, и рестартнуть ядро.

Хотя если ошибки только с блокировкой и их немного , я бы не суетился.

Аватара пользователя
TiRider
Сообщения: 568
Зарегистрирован: Сб июн 07, 2008 12:43

Сообщение TiRider »

Только блокировка, ага :) но логике это не поддается, с чего ради ошибка появилась известно только разрабам утма :lol:

mikkey finn
Сообщения: 1612
Зарегистрирован: Пт ноя 10, 2006 15:23

Сообщение mikkey finn »

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

Ответить