Unifi OS - веб-сервер падает каждый день

Unifi OS - веб-сервер падает каждый день, UniFi Network

Adammp88

Guest

14.01.2026 03:41:00

Я запускаю Unifi OS с несколькими тысячами конечных точек, и мой сервер ежедневно падает, требуя перезагрузки. Веб-интерфейс становится недоступным, и приходится выполнять unifi-os stop / start. После перезапуска скорость ракетная около 5 часов, а потом она замедляется всё сильнее, пока не становится непригодной для работы. Думаю, дело в логах? Кто-нибудь сталкивался с подобным? Unifi OS 5.0.6, Network Application 10.0.16, 48 ядер / 368 ГБ ОЗУ (файлы поддержки приложены)

tjgertge

Guest

09.05.2026 20:59:00

Я боролся с этим несколько месяцев через UI. Просто наткнулся на это. Контроллер управляет 150 сайтами разного размера. Могу подтвердить, что у меня есть несколько сайтов, всё ещё работающих на USG. Могу подтвердить, что список IP, возвращаемый по вашей первой команде, перечисляет эти сайты. Я настроил cron job, как вы предложили, и пока всё работает отлично. До этого мой контроллер вырубался примерно каждые 10 часов.

JHC Guest	#3 23.04.2026 18:54:00 Можешь подтвердить, что эти IP-адреса относятся к USG, EdgeRouter или другим конкретным брендам/моделям?Команда ss -K очищает эти IP?

denterprises Guest	#4 23.04.2026 17:38:00 Я только что подтвердил, что у меня тоже куча IP-адресов, я уже неделями переписываюсь с UBNT, мой сервер UOS крашится как часы каждые 6 дней. Я мониторю статистику сервера через Cacti, и могу сверять по нему часы.

JHC Guest	#5 23.04.2026 16:18:00 Если вы используете netdata, вы должны чётко видеть проблему в разделе Processes -> FDs. У меня pasta hd использует более 67 000 fd, и их количество растёт до того, как я их убиваю через ss -K.

JHC Guest	#6 22.04.2026 13:42:00 Похоже, это та же проблема. Чтобы выполнить команду вручную, без cron, нужно просто: `sudo ss -K state fin-wait-2`

jl_edgetech

Guest

21.04.2026 23:01:00

Привет, JHC. Подтверждаю, что у нас много сайтов работают на USG, а также есть сайты с разными роутерами и только Unifi AP. Когда я запустил первую команду, которую ты написал, увидел кучу IP-адресов. Но я не уверен, что правильно выполнил вторую команду: когда всё зависло, я попытался её запустить, но сервер всё ещё был заблокирован. В итоге я пока настроил ежедневную перезагрузку по cron, и мы как-то выживаем.

JHC Guest	#8 21.04.2026 21:48:00 Нет, они это читают.

cnwatkins Guest	#9 21.04.2026 21:45:00 Просто интересуюсь, открывали ли вы тикет в Ubiquity по этому поводу?

cnwatkins

Guest

#10

21.04.2026 18:43:00

Тоже столкнулся с этой проблемой. Спасибо, что разобрались! В моём случае это сайты, где установлены USG 3P, UAP LR, AC Lite, AC Pro, UAP Pro, US 24 или US 48 PoE 750W, в основном на старых прошивках. Некоторые устройства обновлены, и я собираюсь обновить остальные, чтобы проверить, поможет это или нет. На сайтах без USG используются разные роутеры — либо от провайдера, либо Mikrotik.

JHC

Guest

#11

21.04.2026 15:48:00

Я не знаю точной причины проблемы, кроме того, что она затрагивает ERL/X и USG (оригинальная версия на базе ER). Скорее всего, это связано с конкретным кодом, который используется совместно с offload (но не зависит от включения offload) и применяется Edgerouter для модуля conntrack/NAT. У VyOS около 10 лет изменений, и она работает на новых ядрах, поэтому, вероятно, не подвержена этой очень специфической проблеме. Выглядит это так: [sanatized ips]root@debian-8gb-hil-1:~# ss -ant | grep FIN-WAIT-2
FIN-WAIT-2 0 0 [::ffff:a.b.130.144]:8080 [::ffff:a.b.235.224.15]:58365
FIN-WAIT-2 0 0 [::ffff:a.b.130.144]:8080 [::ffff:a.b.235.224.15]:58366
FIN-WAIT-2 0 0 [::ffff:a.b.130.144]:8080 [::ffff:a.b.235.224.15]:58364
FIN-WAIT-2 0 0 [::ffff:a.b.130.144]:8080 [::ffff:a.b.167.83.125]:41434
FIN-WAIT-2 0 0 [::ffff:a.b.130.144]:8080 [::ffff:a.b.235.224.2]:56246
FIN-WAIT-2 0 0 [::ffff:a.b.130.144]:8080 [::ffff:a.b.183.186.204]:57552
FIN-WAIT-2 0 0 [::ffff:a.b.130.144]:8080 [::ffff:a.b.235.224.2]:42916
FIN-WAIT-2 0 0 [::ffff:a.b.130.144]:8080 [::ffff:a.b.235.224.2]:56244
FIN-WAIT-2 0 0 [::ffff:a.b.130.144]:8080 [::ffff:a.b.167.83.125]:41436
FIN-WAIT-2 0 0 [::ffff:a.b.130.144]:8080 [::ffff:a.b.235.224.0]:58277
FIN-WAIT-2 0 0 [::ffff:a.b.130.144]:8080 [::ffff:a.b.235.224.2]:42912
FIN-WAIT-2 0 0 [::ffff:a.b.130.144]:8080 [::ffff:a.b.235.224.0]:58279
FIN-WAIT-2 0 0 [::ffff:a.b.130.144]:8080 [::ffff:a.b.167.83.125]:41410
FIN-WAIT-2 0 0 [::ffff:a.b.130.144]:8080 [::ffff:a.b.167.83.125]:41432
FIN-WAIT-2 0 0 [::ffff:a.b.130.144]:8080 [::ffff:a.b.192.126.229]:37761
FIN-WAIT-2 0 0 [::ffff:a.b.130.144]:8080 [::ffff:a.b.235.224.2]:42914
FIN-WAIT-2 0 0 [::ffff:a.b.130.144]:8080 [::ffff:a.b.192.126.229]:37759
FIN-WAIT-2 0 0 [::ffff:a.b.130.144]:8080 [::ffff:a.b.235.224.2]:42910
FIN-WAIT-2 0 0 [::ffff:a.b.130.144]:8080 [::ffff:a.b.183.186.204]:57560
FIN-WAIT-2 0 0 [::ffff:a.b.130.144]:8080 [::ffff:a.b.235.224.0]:58278
FIN-WAIT-2 0 0 [::ffff:a.b.130.144]:8080 [::ffff:a.b.235.224.0]:58280
FIN-WAIT-2 0 0 [::ffff:a.b.130.144]:8080 [::ffff:a.b.192.126.229]:37760
root@debian-8gb-hil-1:~# ss -antop | grep pasta | grep FIN-WAIT-2
FIN-WAIT-2 0 0 [a.b.130.144]:8080 [a.b.83.125]:41618 users:(("pasta",pid=754494,fd=280))
FIN-WAIT-2 0 0 [a.b.130.144]:8080 [a.b.224.15]:58430 users:(("pasta",pid=754494,fd=176))
FIN-WAIT-2 0 0 [a.b.130.144]:8080 [a.b.224.2]:43148 users:(("pasta",pid=754494,fd=96))
FIN-WAIT-2 0 0 [a.b.130.144]:8080 [a.b.83.125]:41616 users:(("pasta",pid=754494,fd=187))
FIN-WAIT-2 0 0 [a.b.130.144]:8080 [a.b.224.2]:56498 users:(("pasta",pid=754494,fd=203))
FIN-WAIT-2 0 0 [a.b.130.144]:8080 [a.b.224.2]:56504 users:(("pasta",pid=754494,fd=523))
FIN-WAIT-2 0 0 [a.b.130.144]:8080 [a.b.186.204]:57868 users:(("pasta",pid=754494,fd=220))
FIN-WAIT-2 0 0 [a.b.130.144]:8080 [a.b.224.2]:43150 users:(("pasta",pid=754494,fd=400))
FIN-WAIT-2 0 0 [a.b.130.144]:8080 [a.b.224.0]:58350 users:(("pasta",pid=754494,fd=60))
FIN-WAIT-2 0 0 [a.b.130.144]:8080 [a.b.224.15]:58431 users:(("pasta",pid=754494,fd=234))
FIN-WAIT-2 0 0 [a.b.130.144]:8080 [a.b.126.229]:37829 users:(("pasta",pid=754494,fd=29))
FIN-WAIT-2 0 0 [a.b.130.144]:8080 [a.b.224.0]:58352 users:(("pasta",pid=754494,fd=473))
FIN-WAIT-2 0 0 [a.b.130.144]:8080 [a.b.224.2]:56500 users:(("pasta",pid=754494,fd=377))
FIN-WAIT-2 0 0 [a.b.130.144]:8080 [a.b.126.229]:37831 users:(("pasta",pid=754494,fd=559))
FIN-WAIT-2 0 0 [a.b.130.144]:8080 [a.b.126.229]:37830 users:(("pasta",pid=754494,fd=197))
FIN-WAIT-2 0 0 [a.b.130.144]:8080 [a.b.224.0]:58351 users:(("pasta",pid=754494,fd=221))
FIN-WAIT-2 0 0 [a.b.130.144]:8080 [a.b.83.125]:41620 users:(("pasta",pid=754494,fd=268))
FIN-WAIT-2 0 0 [a.b.130.144]:8080 [a.b.126.229]:37828 users:(("pasta",pid=754494,fd=124))
FIN-WAIT-2 0 0 [a.b.130.144]:8080 [a.b.224.15]:58432 users:(("pasta",pid=754494,fd=270))
У меня есть один мини-сайт с всего одной точкой доступа за ER-Infinity, где этой проблемы нет, у меня она проявляется только на ERL/X и USG, но у меня больше нет ER4/6 в эксплуатации, чтобы проверить.

blunden

Guest

#12

21.04.2026 09:26:00

Знаете, почему затронуты сайты с ERL? Кроме возможности задать IPv4-адрес UniFi Network Application в DHCPv4 Option 43, у них вообще нет никакой интеграции с UniFi, так что я удивлён, что они могут на что-то влиять.
Чтобы было понятно, я не оспариваю ваши результаты. Мне просто любопытно, почему ERL тут могли бы сыграть роль? 🙂
С USG мне всё яснее, если только проблема не вызвана каким-то поведением, проистекающим из частично общей прошивочной базы.

У меня лично два крошечных объекта: один с маршрутизатором VyOS (имеющим общее происхождение Vyatta с EdgeOS), а другой — это просто одна точка доступа L3, принятая на UOS Server за VyOS-роутером. Я не вижу никаких устаревших соединений/дескрипторов на Linux-сервере, где запущен контейнер UOS Server (с использованием Pasta networking).

JHC

Guest

#13

20.04.2026 20:23:00

Я пробовал отключать offload и настраивать таймауты conntrack — безрезультатно. Единственный способ «исправить» проблему для меня был ss -K их. Надеюсь, Ubiquiti сможет воспроизвести проблему и понять, что pasta не будет корректно закрывать (ленивый) conntrack-сокет USG/EdgeRouter с помощью FIN, а нужен RST (Подсказка: socket.setSoLinger(true, 0)

et.fz

Guest

#14

20.04.2026 10:30:00

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

JHC Guest	#15 17.04.2026 06:04:00 У кого-нибудь из вас есть edgerouter'ы или USG за сервером UOS? Удалось выполнить команду выше, чтобы проверить, есть ли сайты, создающие FIN-WAIT-2?

jl_edgetech

Guest

#16

16.04.2026 23:11:00

Тоже столкнулся с такой же проблемой. Всё отлично работало до обновления на Unifi OS, а теперь видим падения каждые 48 часов. 176 сайтов. Надеюсь, они скоро это починят! Перезагружать каждые несколько дней — просто бесит.

robsonh Guest	#17 15.04.2026 23:02:00 У меня тоже такая проблема. Похоже, это происходит каждые 24 часа около 23:00 по британскому времени.

JHC

Guest

#18

10.04.2026 20:09:00

У меня тоже была эта проблема, и она возникла из-за накопления неосиротевших FIN-WAIT-2 информ-соединений, удерживаемых pasta, что в итоге приводило к сбоям информ-запросов, уведомлениям об этих сбоях и 100% загрузке CPU до полной неотзывчивости UOS. На сервере со 100+ сайтами это ТРИГГЕРИЛОСЬ только от ОПРЕДЕЛЕННЫХ (устаревших) клиентских сайтов, где были либо (1) USG + AP и коммутаторы, либо (2) Edgerouter (ERL и ERX на текущей прошивке) с вручную настроенным inform или dhcp option 43 с AP и коммутаторами (без маршрутизатора Unifi).
В моем случае 6 сайтов (из 2 описанных выше типов) из 110 имели постоянно растущее количество FIN-WAIT-2, пока CPU не достигал 100% от процесса pasta (сеть podman). Поскольку pasta удерживала файловый дескриптор открытым (fd=YY), стек TCP Linux считает его используемым/не владельцем, хотя знает, что он мертв, поэтому Linux не закрывает его после стандартных 60 секунд. Затем USG/ERL не завершает рукопожатие, и мы получаем конечный результат с 100% CPU/мертвым UOS.
Чтобы проверить, есть ли у вас эта проблема, введите эту команду и посмотрите. (Она покажет WAN-IP каждого сайта с зависшими процессами, а также их количество. Первая строка будет общим количеством с IP вашего сервера).
ss -ant state fin-wait-2 | grep -oE '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}' | grep -v '127.0.0.1' | sort | uniq -c | sort -nr
Если у вас накапливается несколько IP, у вас тоже эта проблема.
Моим решением было убивать этих зомби через cron, пока проблема не будет решена Ubiquiti внутри podman/pasta/java (запуск этой команды исправит ситуацию без перезагрузки/рестарта сервера UOS):
*/5 * * * * root /usr/bin/ss -K state fin-wait-2 > /dev/null 2>&1
Я пытался менять настройки таймаутов/снижать MTU на Edgerouter — количество уменьшалось, но через некоторое время я сдался, так как оно никогда не падало до нуля.
ЭТОЙ проблемы НЕ БЫЛО при запуске автономной сети (так как она не использует 'pasta').
У меня она НЕ БЫЛА исправлена в версии 5.0.6/Official с Network 10.2.105, но скрипт с -K работает.
@Adammp88 @mrbrivalen, у вас на сайтах, где происходят краши, есть Edgerouter или USG?

mrbrivalen Guest	#19 22.02.2026 18:46:00 Тот же самый

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