Cloud Key v0.10.0 / 5.7.20-10627 случайные перезагрузки с момента последнего обновления

Cloud Key v0.10.0 / 5.7.20-10627 случайные перезагрузки с момента последнего обновления, UniFi Network

Zak95

Guest

18.03.2018 14:13:00

Я не совсем понимаю, что происходит, уже реально раздражает оборудование Ubiquiti. Никогда полностью не был им доволен — слишком много непредсказуемого поведения, которое меня не устраивает. Вот последние логи: устройство было стабильно в течение трёх недель, пока 3 дня назад не вышло последнее обновление, а теперь оно самопроизвольно перезагружалось два дня подряд. Вот логи. Я вообще ничего не делал с Cloud Key, даже не подходил к контроллеру. Питание идёт через US-8-60W, который не показывает никаких проблем, точка доступа запитана с того же свитча, никаких разрывов связи не было.

[2018-03-18 13:17:33,120] <ips-alert-caching> WARN HttpMethodBase - going to buffer response body of large or unknown size. Using getResponseBodyAsStream instead is recommended.
[2018-03-18 13:22:33,144] <ips-alert-caching> WARN HttpMethodBase - going to buffer response body of large or unknown size. Using getResponseBodyAsStream instead is recommended.
[2018-03-18 13:27:33,131] <ips-alert-caching> WARN HttpMethodBase - going to buffer response body of large or unknown size. Using getResponseBodyAsStream instead is recommended.
[2018-03-18 13:32:33,147] <ips-alert-caching> WARN HttpMethodBase - going to buffer response body of large or unknown size. Using getResponseBodyAsStream instead is recommended.
[2018-03-18 13:37:33,124] <ips-alert-caching> WARN HttpMethodBase - going to buffer response body of large or unknown size. Using getResponseBodyAsStream instead is recommended.
[2018-03-18 13:40:49,712] <main> INFO system - [internal] unable to set file permission on /usr/lib/unifi/data/keystore: /etc/ssl/private/unifi.keystore.jks: Operation not permitted
[2018-03-18 13:40:57,770] <main> INFO system - [internal] unable to set file permission on /usr/lib/unifi/data/keystore: /etc/ssl/private/unifi.keystore.jks: Operation not permitted
[2018-03-18 13:41:08,873] <launcher> INFO system - ======================================================================
[2018-03-18 13:41:08,875] <launcher> INFO system - UniFi 5.7.20 (build atag_5.7.20_10627 - release) is started
[2018-03-18 13:41:08,876] <launcher> INFO system - ======================================================================
[2018-03-18 13:41:08,890] <launcher> INFO system - BASE dir:/usr/lib/unifi
[2018-03-18 13:41:08,992] <launcher> INFO system - Current System IP: 192.168.1.106
[2018-03-18 13:41:08,994] <launcher> INFO system - Hostname: UniFi-CloudKey
[2018-03-18 13:41:10,942] <launcher> INFO system - UniFi Cloudkey, UUID = <<STRING HIDDEN BY ME>>
[2018-03-18 13:41:10,946] <launcher> INFO system - Setting LED status to INITIALIZING
[2018-03-18 13:41:25,636] <db-server> ERROR system - [exec] error, rc=100
[2018-03-18 13:41:25,643] <db-server> WARN db - DbServer not shutdown cleanly and need repairing on next startup
[2018-03-18 13:41:46,264] <launcher> INFO webrtc - WebRTC library version: EvoStream Media Server (www.evostream.com) build v2.0.3 - Gladiator - (built for Debian-8.2.0-armhf on 2018-02-18T01:17:37.000) OpenSSL version: 1.0.2l usrsctp version: 6d79bcc19755bc08 libx264 version: 72d53ab2ac7af245 libav version: v0.0.1-alpha.1 compiled on machine: Linux debian-8-2-0-64 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19) x86_64 GNU/Linux
[2018-03-18 13:41:52,287] <sdn-connect> INFO sdn - Controller registered: <<STRING HIDDEN BY ME>>
[2018-03-18 13:41:52,424] <sdn-connect> INFO sdn - Connecting to cloud websocket at wss://device.svc.ubnt.com/device/unifi/v1/<<STRING HIDDEN BY ME>>
[2018-03-18 13:42:01,848] <Ws> INFO sdn - Successfully connected to cloud websocket
[2018-03-18 13:42:03,102] <ips-alert-caching> WARN HttpMethodBase - going to buffer response body of large or unknown size. Using getResponseBodyAsStream instead is recommended.
[2018-03-18 13:47:02,971] <ips-alert-caching> WARN HttpMethodBase - going to buffer response body of large or unknown size. Using getResponseBodyAsStream instead is recommended.
[2018-03-18 13:52:03,064] <ips-alert-caching> WARN HttpMethodBase - going to buffer response body of large or unknown size. Using getResponseBodyAsStream instead is recommended.
[2018-03-18 13:57:03,050] <ips-alert-caching> WARN HttpMethodBase - going to buffer response body of large or unknown size. Using getResponseBodyAsStream instead is recommended.
[2018-03-18 14:02:02,991] <ips-alert-caching> WARN HttpMethodBase - going to buffer response body of large or unknown size. Using getResponseBodyAsStream instead is recommended.

1Poochh Guest	#2 06.10.2018 18:51:00 Рад это слышать. У меня была проблема с micro USB, когда он начал сдавать. Похоже, что какое-то оборудование CK просто бракованное или что-то в этом роде. Я думал, может, CK2 получше. Рад, что у тебя всё работает!

robertotaylor

Guest

04.10.2018 14:38:00

ОБНОВЛЕНИЕ: Во вторник я получил свой новый Cloud Key и сделал на нём чистую установку (без восстановления из резервной копии). Сейчас он работает уже около 36 часов без проблем. И сам Cloud Key, и контроллер не выключались всё это время, чего не могу сказать про оригинальный Cloud Key. Забавно, что первый Cloud Key, который я получил, был новый с USB-C для зарядки, а второй, который я заказал, всё ещё с Micro USB, но мне это не важно, так как питание идёт через коммутатор Ubiquiti PoE. Так что, если у кого-то из вас проблемы с зависанием Cloud Key или контроллера, советую заменить устройство.

ALB123

Guest

04.10.2018 03:22:00

1Poochh - Уф... Я просто в отчаянии. В первые пару недель с моей новой сетью Unifi было всё отлично. Сейчас попробую оформить RMA на этот Cloud Key. Я знаю, что ты тоже разочаровался в Cloud Key, но как думаешь, Cloud Key Gen 2 должен работать лучше? Я не в курсе технических отличий между этими двумя моделями. Всем большое спасибо за помощь до сих пор.

ALB123

Guest

02.10.2018 21:52:00

Спасибо за ваше предложение по поводу Cloud Key. Нужно ли сначала установить программное обеспечение контроллера на мой файловый сервер, а потом уже физически извлекать Cloud Key? И есть ли от этого разница — я понимаю, что в журналах могут появиться пробелы.

robertotaylor

Guest

01.10.2018 02:11:00

Несколько дней назад я купил USG, Cloud Key, Long Range AP и 8-портовый 60W PoE свитч, и с самого начала у меня одни проблемы с Cloud Key. Всё железо обновлено до последней прошивки, контроллер работает на самой свежей версии. Контроллер время от времени просто вылетает, а потом без причины падает и сам Cloud Key. Даже SD-карта перестала обнаруживаться Cloud Key, так что я подумал, что, возможно, карта повреждена или битая и из-за этого всё и глючит. Запускал Cloud Key без неё — но случайные падения не прекратились. Полагая, что Cloud Key неисправен, заказал новый, он должен прийти завтра. Когда получу и настрою, расскажу, если проблема останется. У нескольких моих друзей такое же оборудование, и у них никаких проблем с Cloud Key нет, поэтому они в растерянности и тоже считают, что у меня сломанный Cloud Key.

1Poochh

Guest

29.09.2018 23:33:00

Проблема, скорее всего, в Cloud Key. Я уже больше месяца использую другую систему для контроллера и ни разу не столкнулся с проблемами. Раньше у меня было много подобного, о чём ты писал, именно с Cloud Key. В конце концов я сдался и отказался от него. Советую обратиться в поддержку и сделать RMA для CK. Ты, как и я, попал в число счастливчиков с бракованным CK. Многие, кажется, довольны им, но я точно нет. Что касается WARN из твоих логов, я много читал об этом, и, похоже, это неопасно. Скоро выйдет исправление, но пока его нет. Пока можно просто игнорировать, а как только обновишь USG (скорее всего в следующем крупном релизе), эта проблема исчезнет.

ALB123

Guest

29.09.2018 00:33:00

Я оставил свой контроллер на вкладке Insights > Controller Logs (не знаю, как еще читать логи) и вернулся к этому:

[2018-09-28 19:03:31,349] <ips-alert-caching> WARN HttpMethodBase - Собирается буферизовать тело ответа большого или неизвестного размера. Рекомендуется использовать getResponseBodyAsStream.
[2018-09-28 19:08:31,386] <ips-alert-caching> WARN HttpMethodBase - Собирается буферизовать тело ответа большого или неизвестного размера. Рекомендуется использовать getResponseBodyAsStream.
[2018-09-28 19:13:31,353] <ips-alert-caching> WARN HttpMethodBase - Собирается буферизовать тело ответа большого или неизвестного размера. Рекомендуется использовать getResponseBodyAsStream.
[2018-09-28 19:18:31,364] <ips-alert-caching> WARN HttpMethodBase - Собирается буферизовать тело ответа большого или неизвестного размера. Рекомендуется использовать getResponseBodyAsStream.
[2018-09-28 19:23:31,413] <ips-alert-caching> WARN HttpMethodBase - Собирается буферизовать тело ответа большого или неизвестного размера. Рекомендуется использовать getResponseBodyAsStream.
[2018-09-28 19:28:31,362] <ips-alert-caching> WARN HttpMethodBase - Собирается буферизовать тело ответа большого или неизвестного размера. Рекомендуется использовать getResponseBodyAsStream.
[2018-09-28 19:33:31,367] <ips-alert-caching> WARN HttpMethodBase - Собирается буферизовать тело ответа большого или неизвестного размера. Рекомендуется использовать getResponseBodyAsStream.
[2018-09-28 19:38:31,354] <ips-alert-caching> WARN HttpMethodBase - Собирается буферизовать тело ответа большого или неизвестного размера. Рекомендуется использовать getResponseBodyAsStream.
[2018-09-28 19:43:31,398] <ips-alert-caching> WARN HttpMethodBase - Собирается буферизовать тело ответа большого или неизвестного размера. Рекомендуется использовать getResponseBodyAsStream.
[2018-09-28 19:48:31,402] <ips-alert-caching> WARN HttpMethodBase - Собирается буферизовать тело ответа большого или неизвестного размера. Рекомендуется использовать getResponseBodyAsStream.
[2018-09-28 19:53:31,410] <ips-alert-caching> WARN HttpMethodBase - Собирается буферизовать тело ответа большого или неизвестного размера. Рекомендуется использовать getResponseBodyAsStream.
[2018-09-28 19:58:31,399] <ips-alert-caching> WARN HttpMethodBase - Собирается буферизовать тело ответа большого или неизвестного размера. Рекомендуется использовать getResponseBodyAsStream.
[2018-09-28 20:03:31,345] <ips-alert-caching> WARN HttpMethodBase - Собирается буферизовать тело ответа большого или неизвестного размера. Рекомендуется использовать getResponseBodyAsStream.
[2018-09-28 20:08:31,394] <ips-alert-caching> WARN HttpMethodBase - Собирается буферизовать тело ответа большого или неизвестного размера. Рекомендуется использовать getResponseBodyAsStream.
[2018-09-28 20:13:31,383] <ips-alert-caching> WARN HttpMethodBase - Собирается буферизовать тело ответа большого или неизвестного размера. Рекомендуется использовать getResponseBodyAsStream.
[2018-09-28 20:18:31,367] <ips-alert-caching> WARN HttpMethodBase - Собирается буферизовать тело ответа большого или неизвестного размера. Рекомендуется использовать getResponseBodyAsStream.
[2018-09-28 20:23:31,354] <ips-alert-caching> WARN HttpMethodBase - Собирается буферизовать тело ответа большого или неизвестного размера. Рекомендуется использовать getResponseBodyAsStream.
[2018-09-28 20:28:31,367] <ips-alert-caching> WARN HttpMethodBase - Собирается буферизовать тело ответа большого или неизвестного размера. Рекомендуется использовать getResponseBodyAsStream.

Каждые 5 минут.

Кто-нибудь может объяснить, что это значит? И насколько это серьёзная проблема?

У меня ноль опыта со всем, кроме стандартных роутеров Linksys с встроенным свитчем. Примерно месяц назад я полностью перешёл на UniFi (USG Pro-4, 16-портовый POE свитч, AP-Lite, Cloud Key) — сначала был просто в восторге. Сеть работала невероятно по сравнению с тем, к чему я привык. А теперь апгрейды кажутся сбоят где-то в половине случаев. Иногда и перезагрузки случаются. Пару раз застревал в петле, когда я уже не знал, как выйти из ситуации, кроме как нажать и держать кнопку сброса на USG Pro-4.

1Poochh

Guest

21.08.2018 03:15:00

Я забил на CloudKey. Посмотрел логи JVM — там куча ошибок (hs_err_<PID> логи). В логах тоже полно перезапусков. В ошибках видно, что JVM постоянно запускает полную сборку мусора (full GC). Я обратился в поддержку, но, честно говоря, прошло уже много дней, а толку нет, так что я забил на CK. Запускаю контроллер на микро-десктопе — и никаких проблем.

С тех пор, как я перешёл на микро-десктоп, у меня не пропадает телеметрия, и не приходится каждый день выдёргивать шнур питания, чтобы перезагрузить устройство. Думаю, UBNT не выделили достаточно памяти для стабильной работы CK или не настроили систему так, чтобы она использовала памяти меньше, чем ожидалось. Я работаю Java performance инженером полный рабочий день, так что кое-что в этом понимаю. 😀

В общем, мое мнение — пока стоит перейти на другое устройство.

ArTourter

Guest

#10

31.05.2018 21:34:00

У меня то же самое на unifi 5.7.28 UCK 0.10.1. Похоже, что на другом cloudkey с версией 5.7.23/0.10.1 этого нет. Я даже не сразу понял, что он реально перезагружается, просто заметил, что в статистике на веб-интерфейсе появляются пропуски. Решил посмотреть логи, чтобы понять, что происходит. В контроллере ничего явного нет — просто тишина, а потом unifi запускается заново. Команда "last" показала причину этих перезапусков: действительно, он перезагружается после сбоев, но в логах я не могу найти, что именно вызывает эти сбои:

root@UniFi-CloudKey:/var/log# last
root ttyMT2 Thu May 31 20:06 все еще в сети
reboot system boot 3.10.20-ubnt-mtk Thu May 31 20:06 - 22:22 (02:16)
root ttyMT2 Thu May 31 12:34 - crash (07:31)
reboot system boot 3.10.20-ubnt-mtk Thu May 31 12:34 - 22:22 (09:48)
root ttyMT2 Tue May 29 18:25 - crash (1+18:08)
reboot system boot 3.10.20-ubnt-mtk Tue May 29 18:25 - 22:22 (2+03:57)
root ttyMT2 Fri May 25 00:30 - crash (4+17:55)
reboot system boot 3.10.20-ubnt-mtk Fri May 25 00:30 - 22:22 (6+21:52)
root ttyMT2 Thu May 24 14:05 - crash (10:25)
reboot system boot 3.10.20-ubnt-mtk Thu May 24 14:05 - 22:22 (7+08:17)
root ttyMT2 Mon May 21 20:28 - crash (2+17:36)
reboot system boot 3.10.20-ubnt-mtk Mon May 21 20:28 - 22:22 (10+01:54)
root ttyMT2 Sat May 19 12:26 - crash (2+08:01)
reboot system boot 3.10.20-ubnt-mtk Sat May 19 12:26 - 22:22 (12+09:56)
root ttyMT2 Sat May 19 09:48 - crash (02:37)
reboot system boot 3.10.20-ubnt-mtk Sat May 19 09:48 - 22:22 (12+12:33)
root ttyMT2 Fri May 18 21:29 - crash (12:19)
reboot system boot 3.10.20-ubnt-mtk Fri May 18 21:29 - 22:22 (13+00:53)
root ttyMT2 Fri May 18 12:39 - crash (08:49)
reboot system boot 3.10.20-ubnt-mtk Fri May 18 12:39 - 22:22 (13+09:42)
root ttyMT2 Tue May 15 04:02 - crash (3+08:37)
reboot system boot 3.10.20-ubnt-mtk Tue May 15 04:02 - 22:22 (16+18:20)
root ttyMT2 Mon May 14 02:10 - crash (1+01:51)
reboot system boot 3.10.20-ubnt-mtk Mon May 14 02:10 - 22:22 (17+20:12)
root ttyMT2 Sun May 13 20:36 - crash (05:34)
reboot system boot 3.10.20-ubnt-mtk Sun May 13 20:35 - 22:22 (18+01:46)
root ttyMT2 Thu May 10 23:56 - crash (2+20:39)
reboot system boot 3.10.20-ubnt-mtk Thu May 10 23:55 - 22:22 (20+22:26)
root ttyMT2 Wed May 9 21:53 - crash (1+02:02)
reboot system boot 3.10.20-ubnt-mtk Wed May 9 21:53 - 22:22 (22+00:28)
root ttyMT2 Fri May 4 12:38 - crash (5+09:15)
reboot system boot 3.10.20-ubnt-mtk Fri May 4 12:38 - 22:22 (27+09:44)

wtmp начинается Fri May 4 12:38:26 2018

У меня включены DPI и QOS, которые управляют USGPro, US8-150w и UAP-AC-Pro. Кроме этого ничего особенного — нет VLAN, нет IPS. UCK получает IP по статическому DHCP и питается от свитча. Единственное отличие от другого UCK, который не перезагружается — там QOS не нужен и, соответственно, выключен.

Zak95

Guest

#11

06.04.2018 20:48:00

Я не использовал никаких сертификатов, у меня была одна VLAN и стандартная настройка. Поддержка помочь не смогла, поэтому я сделал RMA, и замена уже возвращается обратно. Сейчас работаю на виртуальной машине с Ubuntu — всё стабильно и гораздо быстрее, так что когда придёт замена cloud key, сразу выставлю её на eBay.

mgaboury_osr Guest	#12 06.04.2018 19:44:00 У меня наблюдается похожая проблема. Случайно не используете ли вы пользовательский SSL-сертификат? Это сертификат с универсальным доменом?

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