Самопроизвольная перезагрузка

Добрый день!

AM75Z4F3, 8.4.3, wb-2606, stable. Вчера было обновление, так что версии должны быть свежие.

Вчера утром (до обновления) и сегодня утором (07-06-2026 05:10:56.501) был выявлен перезапуск правил. Не знаю перезагружался ли весь контроллер, но перезагрузка правил у меня регистрируется в журнале, по такому признаку и вижу проблему.

приложен диагностический архив, доступен только сотрудникам поддержки
(560,8 КБ)

07-06-2026 05:11:02.174 1780798262: Error: Out of memory.

К москиту в это время подключается только homeassistant с другого сервера. На WB нештатных интеграций и модулей нет.

Thinking

Search uploaded documents
Found 5 uploaded document excerpts for ‘wb-rules “Error: Out of memory” restart’

Search uploaded documents
Found 5 uploaded document excerpts for ‘AM75Z4F3 8.4.3 wb-2606 stable reboot rules out of memory’

Search uploaded documents
Found 5 uploaded document excerpts for ‘wb-rules memory leak restart rules’

Здравствуйте! Я — автоматический помощник техподдержки Wiren Board.
Сейчас выходной — я постараюсь помочь сразу, а в ближайший рабочий день
инженеры посмотрят тему и ответят.

По логу похоже не на «самопроизвольную перезагрузку» всего контроллера, а именно на падение wb-rules по нехватке памяти: у вас уже есть строка Error: Out of memory, а после этого служба обычно перезапускается. В базе я не нашёл явной известной проблемы именно для AM75Z4F3 / 8.4.3 / wb-2606 stable, поэтому сейчас важнее понять, что именно съедает память.

Что можно проверить прямо сейчас:

  1. Посмотреть, не убивает ли OOM именно wb-rules или другой процесс:
journalctl -u wb-rules -n 200 --no-pager
journalctl -k -n 200 --no-pager
  1. Проверить, не растёт ли потребление памяти у wb-rules, mosquitto или homeassistant.
  2. Если есть свои правила — временно отключить их пачками и посмотреть, повторится ли ошибка.
  3. Приложить к теме вывод:
cat /etc/wirenboard-release

и фрагмент лога journalctl -u wb-rules -n 200 --no-pager.

Если хотите, я помогу сузить причину по вашему диагностическому архиву: пришлите, пожалуйста, вывод journalctl -u wb-rules -n 200 --no-pager и journalctl -k -n 200 --no-pager.

Примечание: я — ИИ, а не человек; в моих ответах возможны неточности.
Инженеры посмотрят тему в ближайший рабочий день. Если хотите ускорить —
приложите диагностические данные.

Для лога правил судя по всему это как раз после ошибки. До нее ничего лишнего именно по логу сервиса правил нет.

07-06-2026 05:10:56.507 INFO: [wbgo_mqtt] rules-wirenboard-AM75Z4F3-2337: MQTT connection established
07-06-2026 05:10:56.505 WARNING: [wbgo_mqtt] Cleaning up token queue
07-06-2026 05:10:56.501 WARNING: [wbgo_mqtt] MQTT connection lost: EOF

cat: /etc/wirenboard-release: No such file or directory

Похоже перезапуск правил. 15.34.16.

приложен диагностический архив, доступен только сотрудникам поддержки
(564,5 КБ)

Добрый день!

Судя по логам, перезагружается именно wb-rules, а не контроллер. Из возможных причин:

1. Несколько модулей (в частности, реле wb-mr6cu_207, wb-mio-gpio_183 и wb-mao4_221) сейчас недоступны.

2. Какой-то скрипт настойчиво пытается включить Main Fan, но не может достучаться из-за этого движок постоянно загружает одно ядро примерно на 50%.

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

Отпишитесь потом, пожалуйста, по результатам

Все модули подключены и доступны. Причина не в этом. Смотрите лог правил в момент перезагрузки (даты и время обратите внимание):

07-06-2026 05:10:56.554 ERROR: [wbgo_mqtt] MQTT error: connection lost before Subscribe completed
07-06-2026 05:10:56.553 ERROR: [wbgo_mqtt] MQTT error: connection lost before Subscribe completed
07-06-2026 05:10:56.507 INFO: [wbgo_mqtt] rules-wirenboard-AM75Z4F3-2337: MQTT connection established
07-06-2026 05:10:56.505 WARNING: [wbgo_mqtt] Cleaning up token queue
07-06-2026 05:10:56.501 WARNING: [wbgo_mqtt] MQTT connection lost: EOF
07-06-2026 00:03:52.723 INFO: [rule info] Сохранён в кэш PersistentStorage InputEnergyAP: LastDayValue → 8706.6905
07-06-2026 00:03:52.721 INFO: [rule info] Сохранён в кэш PersistentStorage InputEnergyAP: DayValue → 7.353940000000875
07-06-2026 00:03:52.718 INFO: [rule info] Сохранён в кэш PersistentStorage InputEnergyAP: CurDay → 7
06-06-2026 21:56:59.188 INFO: [rule info] Отключен “WaterWorkInd”: wb-mio-gpio_183:2/K7
06-06-2026 21:56:58.688 INFO: [rule info] Отключен “WaterVentil2”: wb-mio-gpio_183:1/K10
06-06-2026 20:27:09.703 INFO: [rule info] Изменён вход DIN “WaterSCHVSPowerK1”: false
06-06-2026 20:27:09.186 INFO: [rule info] Отключен “WaterSCHVSPowerK1”: wb-mio-gpio_183:2/K1

Поведение по модулям, которое вы описываете, выглядит на подобии такого:

08-06-2026 09:01:49.010 INFO: [rule info] Повторная запись выхода “WaterVentil2” в 0: wb-mio-gpio_183:1/K10
08-06-2026 09:01:49.008 INFO: [rule info] Отключен “WaterVentil2”: wb-mio-gpio_183:1/K10
08-06-2026 09:01:48.392 INFO: [rule info] Повторная запись выхода “ModeInd” в 0: wb-gpio/EXT4_K4
08-06-2026 09:01:48.392 INFO: [rule info] Отключен “ModeInd”: wb-gpio/EXT4_K4
08-06-2026 09:01:48.390 INFO: [rule info] Повторная запись выхода “AlarmInd” в 0: wb-gpio/EXT4_K8

И ловится моим скриптом в журнал так (кстати, полная вырезка за 26 год):

08-06-2026 08:57:41.422 INFO: [rule info] Установлен флаг ошибки “ОШИБКА DOUT” 2026-06-08 08:57:41.421+03:00
08-06-2026 00:10:33.391 INFO: [rule info] Установлен флаг ошибки “ОШИБКА DOUT” 2026-06-08 00:10:33.390+03:00
07-06-2026 15:33:40.784 INFO: [rule info] Установлен флаг ошибки “ОШИБКА DOUT” 2026-06-07 15:33:40.783+03:00
06-06-2026 18:28:50.243 INFO: [rule info] Установлен флаг ошибки “ОШИБКА DOUT” 2026-06-06 18:28:50.243+03:00
06-06-2026 18:23:33.714 INFO: [rule info] Установлен флаг ошибки “ОШИБКА DOUT” 2026-06-06 18:23:33.713+03:00
06-06-2026 18:22:35.698 INFO: [rule info] Установлен флаг ошибки “ОШИБКА DOUT” 2026-06-06 18:22:35.697+03:00
28-03-2026 23:48:49.036 INFO: [rule info] Установлен флаг ошибки “ОШИБКА DOUT” 2026-03-28 23:48:49.035+03:00
19-03-2026 22:42:25.084 INFO: [rule info] Установлен флаг ошибки “ОШИБКА DOUT” 2026-03-19 22:42:25.083+03:00
19-03-2026 22:38:46.003 INFO: [rule info] Установлен флаг ошибки “ОШИБКА DOUT” 2026-03-19 22:38:46.002+03:00
19-03-2026 22:35:23.207 INFO: [rule info] Установлен флаг ошибки “ОШИБКА DOUT” 2026-03-19 22:35:23.207+03:00
19-03-2026 22:20:18.968 INFO: [rule info] Установлен флаг ошибки “ОШИБКА DOUT” 2026-03-19 22:20:18.967+03:00
19-03-2026 22:10:36.517 INFO: [rule info] Установлен флаг ошибки “ОШИБКА DOUT” 2026-03-19 22:10:36.516+03:00
19-03-2026 22:02:26.584 INFO: [rule info] Установлен флаг ошибки “ОШИБКА DOUT” 2026-03-19 22:02:26.583+03:00
19-03-2026 22:02:26.133 INFO: [rule info] Установлен флаг ошибки “ОШИБКА DOUT” 2026-03-19 22:02:26.132+03:00
19-03-2026 21:49:08.901 INFO: [rule info] Установлен флаг ошибки “ОШИБКА DOUT” 2026-03-19 21:49:08.901+03:00
19-03-2026 21:42:44.912 INFO: [rule info] Установлен флаг ошибки “ОШИБКА DOUT” 2026-03-19 21:42:44.911+03:00
19-03-2026 21:37:34.911 INFO: [rule info] Установлен флаг ошибки “ОШИБКА DOUT” 2026-03-19 21:37:34.910+03:00
09-03-2026 17:05:42.316 INFO: [rule info] Установлен флаг ошибки “ОШИБКА DOUT” 2026-03-09 17:05:42.315+03:00
09-03-2026 10:29:37.857 INFO: [rule info] Установлен флаг ошибки “ОШИБКА DOUT” 2026-03-09 10:29:37.856+03:00
29-01-2026 20:57:24.963 INFO: [rule info] Установлен флаг ошибки “ОШИБКА DOUT” 2026-01-29 20:57:24.962+03:00
19-01-2026 12:46:59.309 INFO: [rule info] Установлен флаг ошибки “ОШИБКА DOUT” 2026-01-19 12:46:59.309+03:00
19-01-2026 12:46:19.181 INFO: [rule info] Установлен флаг ошибки “ОШИБКА DOUT” 2026-01-19 12:46:19.180+03:00
19-01-2026 12:44:04.186 INFO: [rule info] Установлен флаг ошибки “ОШИБКА DOUT” 2026-01-19 12:44:04.185+03:00
19-01-2026 12:43:58.159 INFO: [rule info] Установлен флаг ошибки “ОШИБКА DOUT” 2026-01-19 12:43:58.158+03:00
19-01-2026 12:42:32.093 INFO: [rule info] Установлен флаг ошибки “ОШИБКА DOUT” 2026-01-19 12:42:32.093+03:00
18-01-2026 20:08:11.003 INFO: [rule info] Сброшен флаг ошибки “ОШИБКА DOUT” 2026-01-18 20:08:11.003+03:00
18-01-2026 20:05:28.993 INFO: [rule info] Установлен флаг ошибки “ОШИБКА DOUT” 2026-01-18 20:05:28.992+03:00
18-01-2026 19:53:40.039 INFO: [rule info] Сброшен флаг ошибки “ОШИБКА DOUT” 2026-01-18 19:53:40.039+03:00
18-01-2026 19:53:06.481 INFO: [rule info] Установлен флаг ошибки “ОШИБКА DOUT” 2026-01-18 19:53:06.480+03:00
08-01-2026 12:38:05.788 INFO: [rule info] Сброшен флаг ошибки “ОШИБКА DOUT” 2026-01-08 12:38:05.787+03:00
08-01-2026 12:33:56.293 INFO: [rule info] Установлен флаг ошибки “ОШИБКА DOUT” 2026-01-08 12:33:56.290+03:00
08-01-2026 11:43:47.063 INFO: [rule info] Установлен флаг ошибки “ОШИБКА DOUT” 2026-01-08 11:43:47.062+03:00
08-01-2026 11:28:54.731 INFO: [rule info] Установлен флаг ошибки “ОШИБКА DOUT” 2026-01-08 11:28:54.730+03:00
08-01-2026 10:33:34.201 INFO: [rule info] Сброшен флаг ошибки “ОШИБКА DOUT” 2026-01-08 10:33:34.200+03:00
08-01-2026 10:30:56.284 INFO: [rule info] Установлен флаг ошибки “ОШИБКА DOUT” 2026-01-08 10:30:56.283+03:00

Это уже неоднократно мной описывалось: подвисание записи в порты, при чём не только по 485, но и WBIO, и лечится оно либо само, либо ручной записью через WEB если ткнуть флажок выхода. Проблема плавающая, иногда месяцами не проявляется, сейчас опять вылезла. Но она никогда не приводила к перезагрузке. И самое главное - её нет во время перезагрузок позавчера. В 07-06-2026 15:33:40.784 действительно есть запись, но с предыдущими 3 не совпадает.

Приложите, пожалуйста, вывод команды apt policy wb-rules

apt policy wb-rules
wb-rules:
Installed: 2.35.1~exp~feature+SOFT+5434~1~gd0333b1
Candidate: 2.35.1~exp~feature+SOFT+5434~1~gd0333b1
Version table:
2.40.0 990
990 http://deb.wirenboard.com/wb8/bullseye stable/main arm64 Packages
*** 2.35.1~exp~feature+SOFT+5434~1~gd0333b1 991
991 http://deb.wirenboard.com/all experimental.rules-token-wait-timeout/main arm64 Packages
100 /var/lib/dpkg/status
2.35.1~exp~feature+SOFT+5434~1~g7103082 991
991 http://deb.wirenboard.com/all experimental.rules-token-wait-timeout/main arm64 Packages

У вас стоит экспериментальная сборка wb-rules, подскажите, почему установили именно ее?

Были какие-то проблемы ранее?

В прошлых обращениях ТП рекомендовала поставить после проявления бага с сохранением правил. Но проблема с записью в порты была как до установки исправления, так и после. А вот с перезагрузкой правил столкнулся впервые за два года.

Советую вам тогда обновиться до последней stable версии 2.40.0, в ней уже исправлены многие проблемы (в том числе фикс вашей текущей проверки).

Предварительно советую сделать бэкап правил и конфигов:

tar czf /mnt/data/wb-rules-backup-$(date +%F).tar.gz /etc/wb-rules /etc/wb-rules-modules

Отключить exp-источник:

mv /etc/apt/sources.list.d/rules.list /etc/apt/sources.list.d/rules.list.disabled

После этого проверьте что в выводе Candidate стал 2.40.0

apt update

apt policy wb-rules

Если Candidate не стал 2.40.0, то скиньте сюда вывод команды apt policy wb-rules и дальнейшие шаги не делайте.

Сделайте “сухой прогон”, должно быть “wb-rules … 2.35.1~exp… → 2.40.0”:

apt-get install -s wb-rules

Если все ок, то обновляйтесь:

apt install wb-rules

Если будут вопросы, то пишите

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

Хорошо, понаблюдаю, сообщу о результате.

Я ещё до перестановки попробовал понаблюдать сколько память занимает москит - top показывает 0.3%, то есть out of memmory в штатной работе не проявляет себя, на сколько я могу судить.

Будем ждать обратную связь, спасибо :slight_smile:

Не помогло, опять перезапустились.

приложен диагностический архив, доступен только сотрудникам поддержки
(552,7 КБ)

Если я правильно проанализировал лог, то в этот раз не вижу перезапуска москита, а вот зависание выходов имело место. В 21.04.23 зарегистрирована перезагрузка правил.