5.9.29 "Контроллер запускается"

5.9.29 "Контроллер запускается", UniFi Network

buzurk

Guest

08.10.2018 23:35:00

Привет! Уже какое-то время использую 5.9.29 SC с форума BETA. С момента выхода обновил cloud key до 0.12.0, и в итоге он переустановил 5.9.29 согласно текущему публичному релизу. Теперь не могу войти в контроллер, появляется ошибка «UniFi Controller запускается...». Перезагружал CK — без толку.

mbello

Guest

22.02.2019 13:53:00

Ты видел мой совет раньше в этой ветке? «В одной части той статьи говорится о запуске mongodb с параметром ---journal. У меня на CK gen1 он часто не срабатывал, если не убрать этот параметр, поэтому теперь я всегда его отключаю.»

craigfisher1062 Guest	#3 21.02.2019 08:50:00 Та же проблема. Дочерний процесс не запускается, и ремонт не может продолжиться.

PancakeBimmer

Guest

15.12.2018 07:23:00

Та же проблема после обновления прошивки до версии 12 с контроллером версии 5.9.29. Пробовал выполнять шаги из статьи, но похоже, что файл журнала повреждён. Что дальше?
root@GFC-CloudKey:/tmp# mongod --dbpath /usr/lib/unifi/data/db --smallfiles --logpath /usr/lib/unifi/logs/server.log --journal --fork
готовится создать дочерний процесс, жду пока сервер будет готов к подключению.
создан процесс: 3854
весь вывод идёт в: /usr/lib/unifi/logs/server.log
файл журнала [/usr/lib/unifi/logs/server.log] существует; скопирован во временный файл [/usr/lib/unifi/logs/server.log.2018-12-15T07-21-16]
ОШИБКА: дочерний процесс завершился с ошибкой 100
root@GFC-CloudKey:/tmp# cat /usr/lib/unifi/logs/server.log
Пт 14 дек 23:21:16.728 [initandlisten] Запуск MongoDB: pid=3854 port=27017 dbpath=/usr/lib/unifi/data/db 32-битный хост=GFC-CloudKey
Пт 14 дек 23:21:16.729 [initandlisten]
Пт 14 дек 23:21:16.729 [initandlisten] ** ВНИМАНИЕ: Это 32-битный бинарник MongoDB.
Пт 14 дек 23:21:16.729 [initandlisten] ** 32-битные сборки ограничены объёмом данных менее 2 ГБ (или ещё меньше при использовании --journal).
Пт 14 дек 23:21:16.729 [initandlisten] ** Подробнее http://dochub.mongodb.org/core/32bit
Пт 14 дек 23:21:16.730 [initandlisten]
Пт 14 дек 23:21:16.730 [initandlisten] версия БД v2.4.10
Пт 14 дек 23:21:16.730 [initandlisten] git версия: nogitversion
Пт 14 дек 23:21:16.730 [initandlisten] информация о сборке: Linux hartmann 3.16.0-4-armmp-lpae #1 SMP Debian 3.16.39-1 (2016-12-30) armv7l BOOST_LIB_VERSION=1_55
Пт 14 дек 23:21:16.730 [initandlisten] аллокатор: system
Пт 14 дек 23:21:16.730 [initandlisten] параметры: { dbpath: "/usr/lib/unifi/data/db", fork: true, journal: true, logpath: "/usr/lib/unifi/logs/server.log", smallfiles: true }
Пт 14 дек 23:21:16.746 [initandlisten] папка журнала=/usr/lib/unifi/data/db/journal
Пт 14 дек 23:21:16.747 [initandlisten] начало восстановления
Пт 14 дек 23:21:16.748 [initandlisten] recover lsn: 134305196
Пт 14 дек 23:21:16.748 [initandlisten] восстановление /usr/lib/unifi/data/db/journal/j._9
Пт 14 дек 23:21:16.749 [initandlisten] ошибка dbexception во время восстановления: 13537 заголовок файла журнала недействителен. Это может означать повреждение файла журнала или, возможно, сбой, при котором секторы в заголовке файла записывались неверным порядком во время аварии (маловероятно, но возможно).
Пт 14 дек 23:21:16.749 [initandlisten] исключение в initAndListen: 13537 заголовок файла журнала недействителен. Это может означать повреждение файла журнала или, возможно, сбой, при котором секторы в заголовке файла записывались неверным порядком во время аварии (маловероятно, но возможно). Завершение работы.
Пт 14 дек 23:21:16.750 dbexit:
Пт 14 дек 23:21:16.750 [initandlisten] завершение работы: закрываю сокеты...
Пт 14 дек 23:21:16.750 [initandlisten] завершение работы: сбрасываю diaglog...
Пт 14 дек 23:21:16.750 [initandlisten] завершение работы: закрываю сокеты...
Пт 14 дек 23:21:16.750 [initandlisten] завершение работы: ожидаю fs preallocator...
Пт 14 дек 23:21:16.750 [initandlisten] завершение работы: блокирую финальный коммит...
Пт 14 дек 23:21:16.750 [initandlisten] завершение работы: финальный коммит...
Пт 14 дек 23:21:16.750 [initandlisten] завершение работы: закрываю все файлы...
Пт 14 дек 23:21:16.750 [initandlisten] closeAllFiles() завершено
Пт 14 дек 23:21:16.750 [initandlisten] завершение работы: удаляю fs lock...
Пт 14 дек 23:21:16.751 dbexit: действительно выхожу сейчас

Хмм...
root@GFC-CloudKey:/tmp# df -h
Файловая система Размер Использовано Доступно Использовано% Точка монтирования
aufs-root 2.9G 14M 2.9G 1% /
udev 10M 0 10M 0% /dev
tmpfs 404M 428K 404M 1% /run
/dev/disk/by-label/userdata 2.9G 14M 2.9G 1% /mnt/.rwfs
/dev/disk/by-partlabel/rootfs 356M 356M 0 100% /mnt/.rofs
tmpfs 1009M 0 1009M 0% /dev/shm
tmpfs 5.0M 0 5.0M 0% /run/lock
tmpfs 1009M 0 1009M 0% /sys/fs/cgroup
tmpfs 1009M 4.0K 1009M 1% /tmp
/dev/mmcblk0p8 11G 815M 9.5G 8% /srv
/dev/mmcblk1p1 7.2G 18M 7.2G 1% /data

pastill

Guest

14.12.2018 23:07:00

@UBNT-cmb Всё ещё жду какого-то ответа или реакции от Ubiquiti — что делать, чтобы уменьшить или полностью убрать проблемы, с которыми сталкиваются все из-за этой ситуации. Также я по-прежнему читаю на https://help.ubnt.com/hc/en-us/articles/217549368-UniFi-Cloud-Key-s-Device-Management-Limit о приемлемом количестве устройств и клиентов, «которыми Cloud Key Gen 1 может спокойно управлять». Могу только сказать, что у меня показатели значительно ниже этого лимита. И могу добавить, что из состояния почти без проблем я сейчас оказался в ситуации с постоянными разного рода сложностями. Например, мой браузер Firefox и антивирус сообщают, что соединение с https://unifi.ubnt.com/# и/или контроллером CK небезопасно. Проблемы с сертификатами. И сам CK даже не хочет подключаться к облаку. Уверенность падает.

chrissearle

Guest

11.12.2018 07:52:00

Мне удалось починить CK с помощью восстановления базы данных, как я и говорил, но после того, как он несколько раз снова сломался, я в итоге махнул на это рукой. Перенёс контроллер на докер-инстанс на своём NAS и отключил CK. Жаль — идея устройства хорошая, но, увы, всё слишком ограничено 🙁

alexpresland

Guest

10.12.2018 23:08:00

Отлично сказано, pastill! Изменять настройки хранения данных на моём CloudKey — это гадание на кофейной гуще, чтобы он снова не упал. Минимум, что там должно быть — мониторинг, оповещения и какой-нибудь индикатор, показывающий, когда база данных вот-вот переполнится и сломается. Мне повезло, что я мог удалённо управлять ПК в этой сети, чтобы через SSH зайти на CloudKey и запустить команды исправления, а не ехать 150 миль туда и обратно, чтобы всё починить.

pastill

Guest

10.12.2018 19:21:00

Приятно (?) узнать источник проблемы. Но если это новое открытие, почему его не заметили раньше? А если оно старое, то ситуация немного напрягает, ведь сейчас мы на версии 5.9.29. Моя первая реакция — вопрос к Ubiquiti: какие у вас немедленные действия? Пока что никаких похвал.

UI-Team

Guest

08.12.2018 02:21:00

Только UCK G1 до сих пор работает на mongodb 2.4, потому что для его архитектуры процессора нет официальной поддержки более новых версий.

Уровни хранения данных на UCK G1 нужно значительно снизить, чтобы избежать проблем во всех, кроме самых маленьких сетей — именно там обычно и возникают сложности. До контроллера версии 5.6.x данных сохранялось не так много. После добавления хранения данных временных рядов ограничения 32-битной ARM-системы стали более заметны.

mbello

Guest

#10

07.12.2018 15:29:00

@RolandDeschain

Только вот мой UCK никогда не теряет питание, он подключён к PoE-коммутатору, который, в свою очередь, подключён к нормальному ИБП. Он падает сам по себе. Но даже если бы питание пропадало, сегодня недопустимо, чтобы из-за этого устройство ломалось. Журналируемые файловые системы, базы данных с поддержкой ACID — всё это решения, доступные разработчикам для создания устойчивого ПО. Конечно, при отключении питания может быть потеря данных, но контроллер не должен так просто от этого прийти в себя и не включаться. Хорошим первым шагом для Ubiquiti было бы начать обновлять своё ПО до более новых версий. MongoDB на UCK работает на версии 2.4.10. Версия 2.6 вышла в 2014 году, а потом были 3.0, 3.2, 3.4, 3.6 и нынешняя 4.0. Надёжность MongoDB сильно выросла за последние 4 года, почему бы этим не воспользоваться?

hlain Guest	#11 06.12.2018 05:09:00 Это тоже решило мою проблему. Огромное спасибо за то, что поделились!

RolandDeschain

Guest

#12

05.12.2018 18:25:00

Проблема с устройством первого поколения в том, что у него нет резервного аккумулятора, поэтому при отключении питания данные могут серьезно повредиться, и компания UBNT мало что может с этим поделать. Вот почему у устройств второго поколения есть аккумулятор, и они корректно завершают работу при отключении питания.

mbello

Guest

#13

05.12.2018 18:19:00

Если у вас CK gen1, лучше привыкать к этим сбоям. У меня они происходят каждые 7-10 дней. Решение — следовать инструкциям из статьи по ремонту базы данных. Иногда приходится править скрипт CK_repair.js и менять количество дней с 7 на 3. В одной из частей статьи нужно запускать mongodb с параметром ---journal. У меня на CK gen1 это часто не работает, если не убрать параметр --journal, что теперь я и делаю всегда. По крайней мере, с опытом всё занимает всего 2-3 минуты, чтобы поднять CK обратно. Просто интересно, почему UBNT до сих пор не починили эту проблему. UBNT, это действительно неприятно, когда твой продукт постоянно подводит пользователей.

cash22 Guest	#14 05.12.2018 17:30:00 Очень рад, что мой поиск в Google привел меня к этой теме. Огромное спасибо!

alexpresland Guest	#15 08.11.2018 00:28:00 У меня была такая же проблема. Запуск восстановления базы данных, как вы советовали, позволил Cloud Key снова запустить сервисы. Спасибо.

Читают тему (гостей: 1)