"зависание" системы


#1

Добрый день. Помогите диагностировать и починить проблему.
За 1.5 месяца эксплуатации уже второй раз происходит какое-то “зависание” системы.

Конфигурация:
WB6 + WBIO-DI-DR-16 (4шт) + WBIO-DO-R1G-16 (4шт) + WB-MIO-E (по rs485) + WBIO-DI-DR-16 (2шт) + WBIO-DO-R1G-16 (2шт)

Симптомы:
Перестают работать выключатели, настроенные через правила на выходы реле. Выполняем перезагрузку (отключаем питание и подаем) - не помогает.
В первый раз решилось отключением от контроллера всех модулей (физически отсоединили) и подключением заново.
Второй раз (сегодня), проверили, что через веб-интерфейс реле переключаются, а через входы - нет. И также, после отсоединения модулей и перезагрузки всё снова запустилось.

Проблему к сожалению наблюдаю не сам, а удаленно. Бываю на объекте в выходные, но подключиться терминально могу.

Что такое может быть? Правила не запускаются? Куда смотреть? Какие логи записать?

лог с контроллера
messages.txt (619.2 КБ)

ориентировочно в 12:00 обнаружились проблемы. пытались перезагрузить и потом еще раз


#2

Добрый день!

Это как замечаете? Можете в этот момент зайти в интерфейс и проверить, правильно ли изменяется состояние входов, и управляются ли вручную выходы? Это поможет отличить проблемы с оборудованием от проблем с движком правил.

Проверить работы сервисов можно так:

service wb-rules status //правила
service wb-mqtt-serial status //подключенное по RS-485
service wb-homa-gpio status //боковые модули, вставленные непосредственно в Wiren Board

#3

Я лично не замечал. Мне звонят и говорят, что “выключатели не работают, нажимаем, а ничего не происходит”.
Оба случая я был далеко от возможности подключиться и посмотреть состояние контроллера, поэтому приходилось действовать оперативно.
По возможности я конечно проверю (хотя очень не хочется чтобы снова возникала такая возможность).
Может есть какие-то готовые скрипты, которые бы запускались и мониторили состояние правил, mqtt, gpio и в случае проблем - выполняли действия для уведомления (это какой-нибудь скрипт)?


#4

Готовых нет.


#5

Ради интереса гляньте Проблемку , звучит похоже


#6

2го января снова повторилось “зависание”.
Успел удаленно выполнить команды статуса сервисов.

Сводка

root@wirenboard-ACWRKP6X:/etc/init.d# service wb-rules status
● wb-rules.service - LSB: MQTT Rule Engine for Wiren Board
Loaded: loaded (/etc/init.d/wb-rules; generated; vendor preset: enabled)
Active: active (running) since Thu 2020-01-02 19:42:45 MSK; 8min ago
Docs: man:systemd-sysv-generator(8)
Process: 3684 ExecStop=/etc/init.d/wb-rules stop (code=exited, status=0/SUCCESS)
Process: 3693 ExecStart=/etc/init.d/wb-rules start (code=exited, status=0/SUCCESS)
CGroup: /system.slice/wb-rules.service
└─3700 /usr/bin/wb-rules -syslog -queue-len 2048 -editdir /etc/wb-rules /usr/share/wb-rules-system/rules/ /etc/wb-rules /usr/share/wb-rules/

Jan 02 19:42:44 wirenboard-ACWRKP6X systemd[1]: Starting LSB: MQTT Rule Engine for Wiren Board…
Jan 02 19:42:45 wirenboard-ACWRKP6X systemd[1]: Started LSB: MQTT Rule Engine for Wiren Board.
root@wirenboard-ACWRKP6X:/etc/init.d# service wb-homa-gpio status
● wb-homa-gpio.service - LSB: MQTT Driver for GPIO-controlled switches
Loaded: loaded (/etc/init.d/wb-homa-gpio; generated; vendor preset: enabled)
Active: active (running) since Thu 2020-01-02 19:39:07 MSK; 12min ago
Docs: man:systemd-sysv-generator(8)
Process: 1722 ExecStart=/etc/init.d/wb-homa-gpio start (code=exited, status=0/SUCCESS)
CGroup: /system.slice/wb-homa-gpio.service
└─2928 /usr/bin/wb-homa-gpio -c /tmp/wb-homa-gpio.do-not-edit.conf

Jan 02 19:38:51 wirenboard-ACWRKP6X systemd[1]: Starting LSB: MQTT Driver for GPIO-controlled switches…
Jan 02 19:39:07 wirenboard-ACWRKP6X wb-homa-gpio[1722]: Starting MQTT Driver for GPIO-controlled switches: wb-homa-gpio.
Jan 02 19:39:07 wirenboard-ACWRKP6X systemd[1]: Started LSB: MQTT Driver for GPIO-controlled switches.
root@wirenboard-ACWRKP6X:/etc/init.d# service wb-mqtt-serial status
● wb-mqtt-serial.service - LSB: MQTT Driver for serial devices
Loaded: loaded (/etc/init.d/wb-mqtt-serial; generated; vendor preset: enabled)
Active: active (running) since Thu 2020-01-02 19:38:53 MSK; 13min ago
Docs: man:systemd-sysv-generator(8)
Process: 1739 ExecStart=/etc/init.d/wb-mqtt-serial start (code=exited, status=0/SUCCESS)
CGroup: /system.slice/wb-mqtt-serial.service
├─1812 /bin/bash -c exec /usr/bin/wb-mqtt-serial -c /etc/wb-mqtt-serial.conf 2>&1 | logger -t serial
├─1821 /usr/bin/wb-mqtt-serial -c /etc/wb-mqtt-serial.conf
└─1822 logger -t serial

Jan 02 19:38:51 wirenboard-ACWRKP6X systemd[1]: Starting LSB: MQTT Driver for serial devices…
Jan 02 19:38:53 wirenboard-ACWRKP6X systemd[1]: Started LSB: MQTT Driver for serial devices.
root@wirenboard-ACWRKP6X:/etc/init.d#

В этот раз помогло отключение питания.

Файл messages “спасти” не удалось, когда 5го числа зашел его забрать - за 2е число уже не было данных. Надо где-то настроить ротацию файлов логов, чтобы подольше хранил.

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

Причем второй контроллер с подобной конфигурацией пока работает стабильно, тьфу-тьфу-тьфу.


#7

07.01.2020 в 20:48 “полечили зависание” перезагрузкой системы отключив питание.
messages_223.txt (951.8 КБ)
Посмотрел логи. Перед “зависанием” заметил такие события:
Jan 7 19:49:32 wirenboard-ACWRKP6X user.warn wb-mqtt-db[1870]: 2020-01-07 19:49:32.148 WARN: Channel data limit is reached: channel wb-adc/A1, row count 10201, limit 10000
Jan 7 19:49:32 wirenboard-ACWRKP6X user.warn wb-mqtt-db[1870]: 2020-01-07 19:49:32.171 WARN: Channel data limit is reached: channel wb-adc/A2, row count 10201, limit 10000
Jan 7 19:49:32 wirenboard-ACWRKP6X user.warn wb-mqtt-db[1870]: 2020-01-07 19:49:32.193 WARN: Channel data limit is reached: channel wb-adc/A3, row count 10201, limit 10000
Jan 7 19:49:32 wirenboard-ACWRKP6X user.warn wb-mqtt-db[1870]: 2020-01-07 19:49:32.222 WARN: Channel data limit is reached: channel wb-adc/A4, row count 10201, limit 10000
Jan 7 19:49:32 wirenboard-ACWRKP6X user.warn wb-mqtt-db[1870]: 2020-01-07 19:49:32.247 WARN: Channel data limit is reached: channel wb-adc/Vin, row count 10201, limit 10000
Jan 7 19:53:32 wirenboard-ACWRKP6X user.warn wb-mqtt-db[1870]: 2020-01-07 19:53:32.151 WARN: Channel data limit is reached: channel system/Current uptime, row count 10201, limit 10000
Jan 7 19:53:32 wirenboard-ACWRKP6X user.warn wb-mqtt-db[1870]: 2020-01-07 19:53:32.189 WARN: Channel data limit is reached: channel power_status/Vin, row count 10201, limit 10000
Jan 7 20:03:32 wirenboard-ACWRKP6X user.warn wb-mqtt-db[1870]: 2020-01-07 20:03:32.158 WARN: Channel data limit is reached: channel hwmon/CPU Temperature, row count 10201, limit 10000

Могут ли они приводить к “зависанию”?


#8

Могу предположить, что зависает сервис wb-rules. Что стоит попробовать:

  1. при следующем зависании выполнить

service wb-rules restart

  1. если поможет, то попробовать вот это Ошибка: wb-rules check failed, reload wb-rules

#9

в прошлый раз перезапуск wb-rules не помогал, также как reboot без отключения питания.
но попробую


#10

Если не поможет, то следующий кандидат на перезапуск - сервис mosquitto.


#11

настройте логгирование на внешний сервер что бы понять в чем проблема. так же гляньте что по свободному месту на контроллере. по-умолчанию там есть логгирование данных mosquitto в базу данных. возможно хранилище переполнилось


#12

около 3х недель назад поменяли первый контроллер на резервный, обновили wb-rules на версию 2.2

2 недели назад начал “зависать” второй контроллер - там тоже выполнил обновление wb-rules.

Вот сегодня второй контроллер снова “завис” (уже с новыми wb-rules).
Перезапуск сервисов wb-rules не помог. также не помог перезупуск сервиса wb-mqtt-serial.
При перезапуске mosquitto соединение с сервером пропало и пришлось прибегнуть к жесткой перезагрузке.

Прикладываю лог. “Зависание” заметили в 18:00-18:05 по времени лога, т.к. потом уже подключился я и делал перезапуск сервисов.
в 18:06 перезапустили wb-rules и попробовали понажимать на кнопки - в логе видно события из правил, но свет не переключался.

Также прикладываю файл правил, возможно у меня с ними проблема и я там накрутил лишнего.messages_170_20200129.txt (855.0 КБ)
level1.js.txt (24.7 КБ)


#13

Перейти на node-red и забыть о wb-rules! у меня правил на 500кб, более 500 нод используется, ничего не зависает.


#14

что-то мне подсказывает что проблема не в правилах, а в чем-то другом.
т.к. даже перезагрузка служб не дала результата. только обесточивание модулей


#15

Проверьте пожалуйста подключение боковых модулей ввода-вывода. Скорее всего, проблема в них.


#16

С виду вроде нормально сидят, плотно воткнуты. Я конечно их еще раз перевоткну.
А может быть какое-то зависание этой шины на стороне модулей, а не контроллера? Типа входы (подключены первыми) срабатывают (видно по логам правил), а выходы “отвалились”?


#17

Столкнулся сегодня с аналогичной проблемой:
Свет остался гореть, выключатели и реле на кнопки не реагируют. Реле ничего не переключают. Что не горит (свет) - не включить, а то, что горит - не выключить.

Сначала к контроллеру справа подключен модуль реле 16 контактов, потом 2 модуля по 14 контактов сухих контактов и потом модуль на краны.
В веб интерфейсе никакой реакции ни на подключенные кнопки, ни на нажатия на сами переключатели реле не было. Удаление модулей из конфигурации ни к чему не привело, добавил обратно. Ни перезагрузка через консоль, ни по питанию не разблокировала реле.

Помогло только выключение питания на контроллере с последующим физическим отсоединением всех 4-х доп модулей. В момент отсоединения реле выключились (хотя сам контроллер был выключен). После обратного присоединения и включении питания система вернулась к нормальной работе, наблюдаю за поведением далее


#18

Возможные причины в порядке уменьшения вероятности как мне видится:

  1. Плохой контакт в боковых разъемах модулей. Что можно сделать - проверить, что штырьки не погнуты, модули плотно прижаты друг другу на динрейке.
  2. Непропай одного из боковых разъемов на любом модуле или контроллере. Что можно сделать - снять задние крышки, посмотреть пайку разъемов.
  3. Зависание чипа в модуле (никогда не наблюдали, но все же). Как можно диагностировать - при повторении проблемы сначала перезагрузить контроллер по питанию (кнопкой на корпусе), проверить что не помогло. Потом перезагрузить контроллер, полностью отключив питание, стараясь не трогать модули и контроллер. Если помогло - значит зависал чип.
    Почему так - при выключении контроллера кнопкой или его перезагрузке по вотчдогу, питание на боковых модулях остается, как раз с целью сохранения состояния реле.

#19

У меня 2 раза такое, боковые модули перестают работать, при этом все сервисы работают
ребут не помогает.

Первый раз вылечил таким образом: в hardware конфиге удалил все боковые устройства, сохранил и передобавил.


#20

Т.е. как будто достаточно переинициализацию сделать? Если это так, то значит на программном уровне можно восстановить работу.
Осталось выяснить как это сделать и проверить.