Вот мое решение проблемы.
По какой то не понятной мне причине, в базе данных изменилась структура следующей таблицы -
notification_borders, значение которое должно быть выглядит так:
Код: Выделить всё
mysql> SELECT value FROM utm5_settings WHERE variable='notification_borders' ;
+---------+
| value |
+---------+
| 0.1 2 5 |
+---------+
1 row in set (0.00 sec)
У нас же было вот так:
Код: Выделить всё
mysql> SELECT value FROM utm5_settings WHERE variable='notification_borders' ;
+--------------+
| value |
+--------------+
| 0,1,15,30,50 |
+--------------+
1 row in set (0.00 sec)
Из-за этого конечно же и база посыпалась и в админку я не мог зайти чтобы убить не правильные значения.
В
verificator.log у меня сыпались ошибки:
Код: Выделить всё
billing>less /netup/utm/log/verificator.log
-- Verificator
-- You have to backup UTM5 database!
-- Affected tables list at the end of file
-- ERROR service link 3137 refer to service 166 which not exist
-- SQL DESC no sql, delete slink or create service
-- ERROR unexpected row in periodic_service_links with id 3137
-- SQL DESC delete row (NOT RECOMMENDED)
UPDATE periodic_service_links SET is_deleted=1 WHERE id='3137';
-- WARNING slink 3137 exists only in dtagg_periodic
-- SQL DESC check slink exists and delete dtagg_periodic entry for deleted slink
UPDATE dtagg_periodic SET is_closed=1 WHERE slink_id=3137;
-- 2 errors
-- 1 warnings
-- affected tables: dtagg_periodic periodic_service_links
Видно, что явно это не в тему. И никак не связано с
notification_borders, но об этом чуть позже.
В логах
/var/log/utm/core_start.log сыпалось такое критическое сообщение:
Код: Выделить всё
*CRIT : Jan 31 14:09:48 UTM5 DBA: can't parse notification_borders 0.000000
*CRIT : Jan 31 14:09:48 UTM5 DBA: can't parse notification_borders 0.000000
*CRIT : Jan 31 14:09:48 UTM5 DBA: can't parse notification_borders 0.000000
*CRIT : Jan 31 14:09:48 UTM5 DBA: can't parse notification_borders 0.000000
*CRIT : Jan 31 14:09:48 UTM5 DBA: can't parse notification_borders 0.000000
В /
var/log/utm/main.log тоже самое...
Код: Выделить всё
*CRIT : Jan 31 12:37:30 UTM5 DBA: can't parse notification_borders 0.000000
*CRIT : Jan 31 12:37:30 UTM5 DBA: can't parse notification_borders 0.000000
*CRIT : Jan 31 12:37:30 UTM5 DBA: can't parse notification_borders 0.000000
*CRIT : Jan 31 12:37:30 UTM5 DBA: can't parse notification_borders 0.000000
*CRIT : Jan 31 12:37:30 UTM5 DBA: can't parse notification_borders 0.000000
Ну точно с базой проблемы...
Собственно не долго думая, делаем backup базы данных.
Код: Выделить всё
/var/backups/utm5/db/>mysqldump -u root -p UTM5 > UTM5.sql
Должно выскочить сообщение с указанием пароля для доступа. Вводите свой пароль.
Затем "тушим" ядро. Так как, мои попытки выключить его через команду
/usr/local/etc/rc.d/utm5_core.sh stop не увенчались успехом, ядро минут пять останавливалось так не остановившись.
Решил "убить" с помощью kill:
где
number pid запущенный процесс в системе (ядро utm). У меня это был 768.
Дальше чистим логи, т.к. из-за этой конители папка куда пишется лог, переполнилась, и начала ругаться на место на диске.
Код: Выделить всё
/var/log: write failed, filesystem is full
Если после этого размер не изменится, то перезапустите систему. После перезапуска нужно снова будет "вырубить" ядро.
Далее заходим в базу:
и исполняем запрос в базу данных.
Код: Выделить всё
mysql>UPDATE utm5_settings SET value=0.1 WHERE variable='notification_borders';
После чего проверяем изменения:
Код: Выделить всё
mysql>SELECT value FROM utm5_settings WHERE variable='notification_borders';
+-------+
| value |
+-------+
| 0.1 |
+-------+
1 row in set (0.00 sec)
Вроде изменилось. Тфу тфу. Двигаемся дальше.
Делаем бэкап базы на всякий случай.
Код: Выделить всё
/var/backups/utm5/db/>mysqldump -u root -p UTM5 > UTM5_last.sql
Далее идем в верификатор, у меня он тут:
/netup/utm5/log/verificator.log
Код: Выделить всё
-- Verificator
-- You have to backup UTM5 database!
-- Affected tables list at the end of file
-- ERROR service link 3137 refer to service 166 which not exist
-- SQL DESC no sql, delete slink or create service
-- ERROR unexpected row in periodic_service_links with id 3137
-- SQL DESC delete row (NOT RECOMMENDED)
UPDATE periodic_service_links SET is_deleted=1 WHERE id='3137';
-- WARNING slink 3137 exists only in dtagg_periodic
-- SQL DESC check slink exists and delete dtagg_periodic entry for deleted slink
UPDATE dtagg_periodic SET is_closed=1 WHERE slink_id=3137;
-- 2 errors
-- 1 warnings
-- affected tables: dtagg_periodic periodic_service_links
Смотрим, что нам нужно апдейтить. И делаем это.
Код: Выделить всё
mysql> UPDATE periodic_service_links SET is_deleted=1 WHERE id='3137';
Query OK, 1 row affected (0.04 sec)
Rows matched: 1 Changed: 1 Warnings: 0
mysql> UPDATE dtagg_periodic SET is_closed=1 WHERE slink_id=3137;
Query OK, 1 row affected (0.04 sec)
Rows matched: 1 Changed: 1 Warnings: 0
Смотрим, что получилось после этих манипуляций:
Код: Выделить всё
mysql> SELECT * FROM periodic_service_links WHERE id='3137';
+------+------------+--------------------+---------------------------+------------+------------+-------------+----------+---------------+-----------------+--------------------+----------------------+----------------+------------+
| id | is_blocked | discount_period_id | discounted_in_curr_period | start_date | is_planned | expire_date | need_del | unabon_period | unprepay_period | start_block_unabon | start_block_unprepay | is_invoice_set | is_deleted |
+------+------------+--------------------+---------------------------+------------+------------+-------------+----------+---------------+-----------------+--------------------+----------------------+----------------+------------+
| 3137 | 0 | 276 | 0 | 1244182778 | 0 | 2000000000 | 1 | 0 | 0 | 0 | 0 | 0 | 1 |
+------+------------+--------------------+---------------------------+------------+------------+-------------+----------+---------------+-----------------+--------------------+----------------------+----------------+------------+
1 row in set (0.00 sec)
mysql> CHECK TABLE `discount_periods`;
+-----------------------+-------+----------+----------+
| Table | Op | Msg_type | Msg_text |
+-----------------------+-------+----------+----------+
| UTM5.discount_periods | check | status | OK |
+-----------------------+-------+----------+----------+
1 row in set (0.80 sec)
Вроде как все в порядке.
Делаем бэкап на всякий случай. И перегружаемся.
Все должно запуститься.
Удачи! И не дай Бог вам с этим столкнуться...
последнюю ошибку вообще не понимаю куда прикрутить 