CloudKey не запускает Controller.

CloudKey не запускает Controller., UniFi Network

MonkeyC

Guest

24.01.2017 11:19:00

Мой CK сильно упал после отключения электроэнергии, ИБП в итоге сдох, и вместе с ним упал и CK. Он загрузился, и я могу зайти на локальную страницу администратора, где указано, что контроллер остановлен. Есть какие-то советы? Не очень понимаю, с чего начать диагностику. У меня есть доступ по SSH и возможность перезагрузить, если нужно. У меня есть старый бэкап, но также был включён автосохран. Откуда можно scp скопировать файл бэкапа? Нужна ли дополнительная информация?

SFPadmin

Guest

10.04.2019 12:27:00

«Нет никаких причин, по которым это устройство вообще должно было поступить в производство...» — Хорошо сказано. Они знают о проблеме и просто выпустили облачный ключ второго поколения. Так они просто зарабатывают больше денег... Нам бы хотелось иметь возможность вернуть их неисправные облачные ключи первого поколения и получить обратно деньги!

littlewolf Guest	#3 24.01.2019 05:36:00 Пластик ни при чём (к тому же его можно переработать во что-то вроде PiHole или что-то в этом роде...). Просто MongoDB — это полнейший отстой.

cstout

Guest

24.01.2019 05:02:00

v0.12.2 тоже сломал мой CK при перезагрузке. Честно, я в шоке от того, насколько плохо этот продукт разработан, как долго его вообще продавали и насколько ужасно его поддерживают. Если работают с CK, обязательно наткнёшься на мозголомные проблемы. Но эй, за дополнительные $180 можно купить новый железный компонент, который исправляет одну из самых больших известных проблем с повреждением данных. Жаль, что этот дорогой кусок белого пластика не отозвали с рынка.

ravenlord

Guest

22.01.2019 05:00:00

Та же проблема у меня, с версии 0.12.0 до 0.12.2. Но у меня есть только авторезервная копия... Если я сбрасываю настройки моего CK, я не могу восстановить конфигурацию. Что мне делать, чтобы не потерять настройки сейчас? Может, просто ждать скорого обновления от Ubiquiti? Невозможно, чтобы при каждом обновлении возникали проблемы!

mHumle

Guest

04.01.2019 08:35:00

Привет! Только что столкнулся с этим на v0.12.029 - 5.9.29.11384-1. Всё началось после перезагрузки CK через GUI. Management GUI (8443) так и не вернулся. Доступ к настройкам CK был, а вот GUI — нет. Пробовал перезагрузку — безуспешно. Выключал питание и включал снова — тоже не помогло. Пытался восстановить из файла (с установленной SD-карты) прямо поверх существующей конфигурации — тоже без результата. Через CK GUI сделал RESET CLOUDKEY. Когда он загрузился, выполнил «stop UNIFI», а затем восстановил последний файл. Всё заработало. (Конечно, при первой настройке CK нужно сменить пароль.) Когда Management GUI вернулся, он был немного «капризным» — всё зависит от того, насколько старый был восстановленный файл, но в моём случае достаточно было просто принять (ADOPT) устройства со статусом «Managed by other» — никаких особых процедур.

efaccou

Guest

30.11.2018 01:04:00

В моём случае MongoDB не запускалась, потому что база данных стала слишком большой. Запуск mongo вручную без журналирования позволил мне хотя бы запустить mongo...
systemctl stop unifimongod --dbpath /usr/lib/unifi/data/db --port 27117 --unixSocketPrefix /usr/lib/unifi/run --noprealloc --nohttpinterface --journal --smallfiles --bind_ip 127.0.0.1
После этого я смог выполнить шаги из «UniFi - How to Remove (Prune) Older Data and Adjust Mongo Database Size», чтобы уменьшить базу данных, что позволило снова запустить контроллер.

Uberseehandel Guest	#8 10.04.2019 15:44:00 Если бы ты переписал это как «Я не знаком с MongoDB», это выглядело бы гораздо правдоподобнее.

markmark Guest	#9 31.12.2017 11:54:00 Та же проблема — не удаётся установить их у клиентов с таким типом ошибки.

Bikeras Guest	#10 25.11.2021 16:40:00 У меня немного другая проблема. Не могу запустить сеть, кто-нибудь может помочь?

Uberseehandel

Guest

#11

10.04.2019 18:48:00

Так значит, ты разбираешься лучше таких компаний, как City of Chicago, Telefonica, Sega, Gap, Twitter, Astra Zenica, Nokia, Medtronic, Adobe, Bouygues, EAE, Bay, Google, Cisco, SAP, Facebook, Genentech, Verizon, NBC, Vivent, HMRC, Compare the Market, Barclays, Royal Bank of Scotland, Amadeus, KPMG, Aer Lingus?

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

littlewolf

Guest

#12

10.04.2019 17:27:00

Вы можете сами загуглить список крупных проектов, которые бросили MongoDB, посчитав её бесполезным хламом. И это я уж совсем не беру в расчет недавнюю путаницу с лицензированием, которая, возможно, окончательно отпугнёт оставшихся бедняг, решившихся использовать этот отвратительный (а не кстати ACID – игра слов) хлам.

rwojo

Guest

#13

29.12.2017 02:38:00

Вау, настроил здесь новый Cloud Key и отключил его, чтобы изменить некоторые подключения. Теперь могу зайти на встроенный веб-сервер, но не могу войти в Unifi и не вижу его на unifi.ubnt.com. Это полный беспорядок. Автоматического резервного копирования на SD нет, к счастью, есть одна копия в /srv/unifi/data/backup.

asnell

Guest

#14

12.11.2018 21:23:00

В моём случае файлы журнала были повреждены. Это можно проверить, попробовав восстановиться через журнал: /usr/bin/mongod --dbpath /usr/lib/unifi/data/db --journal
Это не сработало, и mongo не позволил мне использовать одновременно --repair с переключателем --journal или наоборот. Поэтому я удалил файлы журнала, запустил ремонт, и всё снова заработало — правда, с потерей нескольких часов статистики.
systemctl stop unifi
mv /usr/lib/unifi/data/db/journal /usr/lib/unifi/data/db/journal.corrupt
/usr/bin/mongod --dbpath /usr/lib/unifi/data/db --repair
chown unifi:unifi /usr/lib/unifi/data/db/*
systemctl start unifi

v0rts Guest	#15 05.10.2018 16:09:00 Отличная находка, спасибо, что поделились!

grahamrb

Guest

#16

05.10.2018 06:44:00

Для тех, кто тоже столкнулся с этой проблемой, я понял, что нужно просто починить MongoDB. Всё довольно просто: подключаетесь по ssh и следуете инструкциям по ремонту здесь: https://docs.mongodb.com/manual/tutorial/recover-data-following-unexpected-shutdown/ Конкретно эта команда вам понадобится: /usr/bin/mongod --dbpath /usr/lib/unifi/data/db --repair После этого меняете владельца базы обратно на unifi и запускаете приложение через интерфейс cloud key:

cd /usr/lib/unifi/data/db
chown unifi:unifi *

Надеюсь, это кому-то поможет.

dickkoers Guest	#17 25.09.2018 14:55:00 То же самое и у меня, странно! Холодная перезагрузка или нажатие кнопки в интерфейсе ни на что не повлияли, помогла только перезагрузка через ssh! Кстати, у меня версия 5.8.30.

v0rts

Guest

#18

23.08.2018 18:31:00

Со мной только что это случилось, и это одна из первых тем, которые я нашёл через поиск в Google, но тут почти ничего толкового не было. Зато я нашёл вот это руководство, которое реально помогло: https://help.ubnt.com/hc/en-us/articles/360000128688-UniFi-Troubleshooting-Offline-Cloud-Key-and-Other-Stability-Issues. Кстати, в итоге мне пришлось сбросить настройки до заводских через ssh (это как раз описано в приведённом руководстве).

maui86

Guest

#19

15.02.2018 05:27:00

Было бы лучше, если бы вы регулярно включали и выключали свою сеть каждый день. При этом сначала нужно отключить питание Cloud Key через контроллер, чтобы избежать повреждения базы данных. А когда сеть снова включится после выключения, ваша Cloud Key автоматически запустится без каких-либо проблем.

cliffclof Guest	#20 15.02.2018 04:29:00 Есть ли шанс, что это исправят с функцией восстановления после отключения питания? Мне нужно использовать это в сети с ежедневным включением и выключением электроэнергии.

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