Перезагрузка контроллера

#1

Добрый день.
Наполняю правила нужной мне логикой, столкнулся с тем, что контроллер перезагружается в случайное время. Ничего критичного в логах не вижу. Ставил мониториться вывод логов в реалтайме по ssh, сегодня утром словил ребут, в аттаче полный кусок лога, который сохранился в терминале.

Грешу на cron правила. Именно после них стал ловить ребуты, но по правде говоря, до них я особо не мониторил состояние железяки, может и без них перезагружалась, но я не замечал.
Проблемы с питанием исключены - используется модуль UPS v2.

Теперь про сами cron правила: написал их для zigbee устройств: одно проверяет не умирает ли у кого-то из устройств батарейка и присылает в телеграм уведомление, что пора менять, второе проверяет когда устройство последний раз было в сети, если отсутствовало более 12 часов, то тоже шлется сообщенеие в телеграм.

В телеграм сообщения шлю через curl post запросом.

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

wb.log.txt (91.4 КБ)

#2
#3

Добрый день. А лог с контроллера в момент перезапуска?
Да, попробуйте остановить watchdog - скорей всего будет понятней из-за чего перезапускается.

#4

Подскажите, пожалуйста, как его вытащить? Приаттачу, как дома буду.

Watchdog отключить для начала софтово хватит?

#5

https://wirenboard.com/wiki/Просмотр_файлов_контроллера_с_компьютера

Да.

#6

это я знаю =) я имел ввиду где лог сохраняется? мне просто казалось, что после перезагрузки он теряется

#7

Нет, в файле(лах) var/log/messages*

#8

нашел момент перезапуска, но в нем в логах тишина, удалил все лишнее, тысячи однотипных строк с логами батареек зигби девайсов, оставил сам момент перезапуска, пару секунд до него и несколько минут послеmessages.1.log.txt (55.7 КБ)

Вочдог выключил, буду мониторить

#9

Недавно полностью обновил WB, тоже начались перезагрузки, видимо из-за mqtt, но по логам не могу понять что не так. Serial конфиг перенастраивал с нуля, до этого с таким конфигом все работало без перезагрузок.

В логе последние записи посмотрите, где-то в 5:43 случилась перезагрузка вб

wb-mqtt-serial.conf (11.0 КБ)
messages.txt (804.3 КБ)

2021-01-27_09-21-54
2021-01-27_09-21-542554×1850 2.05 MB

#10

Да,

Jan 26 00:28:01 wirenboard-A66HCOB6 cron.info CRON[28586]: (root) CMD (/usr/share/wb-daemon-watchdogs/check_confed.sh 2>&1 | logger -t wb-daemon-watchdogs)

После отключение WD - перезапускался?

Тоже советую остановить WD

#11

после отключения WD не перезагружался еще ни разу, но я и правила поменял, сделал опрос zigbee устройств как и планировалось в “прод”, может оно повлияло

1 симпатия
#12

Добрый день!
Пришлите, пожалуйста, фото, как запитан контроллер, и что подключено к нему.
Когда было сделано обновление?
Что ещё менялось в контроллере / подключении внешнего оборудования?
После перезагрузки контроллер стартует нормально?
Когда случились три последние внезапные перезагрузки?

#13

Все в щите, закрыто, показать невозможно. Питание 24В от блока 320Вт.
Год стабильной работы, ничего не менял физически, только софт обновил.
Перезагрузки теперь каждый день случаются, обычно на ночь выпадают, 4-5 утра, бывало и утром. Стартует контроллер как ни в чем ни бывало. Что-то с mqtt драйвером стало, как выщемить ошибку - не знаю.

#14

Проще всего - отключить watchdog и посмотреть, что перестанет работать.

#15

Вчера перезагружал контроллер для тестирования отправки смс при инициализации wb-rules. До этого на контроллере был отключен WD. После перезагрузки, он, естественно, поднялся и сегодня же перезагрузил контроллер. В логах в момент перезагрузки вижу это:

Feb  4 07:06:01 wirenboard-A66HCOB6 authpriv.info CRON[711]: pam_unix(cron:session): session opened for user root by (uid=0)
Feb  4 07:06:01 wirenboard-A66HCOB6 cron.info CRON[715]: (root) CMD (/usr/share/wb-daemon-watchdogs/check_confed.sh 2>&1 | logger -t wb-daemon-watchdogs)
Feb  4 07:06:05 wirenboard-A66HCOB6 authpriv.info CRON[711]: pam_unix(cron:session): session closed for user root
Feb  4 07:08:34 wirenboard-A66HCOB6 syslog.info syslogd started: BusyBox v1.22.1
Feb  4 07:08:36 wirenboard-A66HCOB6 user.notice kernel: klogd started: BusyBox v1.22.1 (Debian 1:1.22.0-19+b3)
Feb  4 07:08:36 wirenboard-A66HCOB6 user.info kernel: [    0.000000] Booting Linux on physical CPU 0x0
Feb  4 07:08:36 wirenboard-A66HCOB6 user.notice kernel: [    0.000000] Linux version 4.9.22-wb6 (root@wbdevenv) (gcc version 6.3.0 20170516 (Debian 6.3.0-18) ) #2 SMP Wed Dec 9 16:55:10 UTC 2020
Feb  4 07:08:36 wirenboard-A66HCOB6 user.info kernel: [    0.000000] CPU: ARMv7 Processor [410fc075] revision 5 (ARMv7), cr=10c5387d
Feb  4 07:08:36 wirenboard-A66HCOB6 user.info kernel: [    0.000000] CPU: div instructions available: patching division code
Feb  4 07:08:36 wirenboard-A66HCOB6 user.info kernel: [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instruction cache
Feb  4 07:08:36 wirenboard-A66HCOB6 user.info kernel: [    0.000000] OF: fdt:Machine model: Wiren Board rev. 6.7.0 (i.MX6UL/ULL)

Пробовал вручную выполнять check_confed.sh и всегда всё проходит без каких-либо проблем.
Что этот скрип делает?
Подписывается на рандомный топик, шлет в него сообщение и затем проверяет ответ. Если ответ пустой, то перезапускает wb-mqtt-confed сервис? Но откуда перезагрузка всей железяки целиком?
З.Ы. до запуска WD контроллер отработал без проблем неделю.

#16

@a1xb @Andrej_Popov
пока по логам из /var/log/messages не видно ничего подозрительного.
Сделайте, пожалуйста, по возможности следующее:

  1. Напишите, есть ли устройства, которые запитаны от контроллера, или от одного БП с контроллером. Если есть, переключите их временно на другие БП.
  2. Напишите, есть ли в вашем контроллере модуль сотовой связи.
  3. Если есть возможность, организуйте постоянное подключение к отладочному порту контроллера, и собирайте с него вывод - в нём с большей вероятностью окажется полезная информация.
#17

HDR-60-24 питает WB-UPS v2 от которого запитан контроллер + 3 DI-14 модуля + через vout 2 датчика msw v3. 5 реле mr6c v2, 1 шт мини реле и диммер КПИЦ запитаны напрямую от БП, в обход UPS модуля. По сути, можно считать, они запитаны от разных БП.

есть, 4g, но он пока не особо используется, в системе всего одно правило на отправку СМС при запуске движка правил.

Организовал, подцепил к ноуту на 24/7
Что именно там мониторить? Я пока вывел tail -f /var/log/messages

#18

Давайте попробуем максимально исключить возможные источники проблем.

  1. Проверьте, пожалуйста, на всякий случай, что WB-UPS v.2 нормально отрабатывает при пропадании питания с БП.
  2. Перевесьте, пожалуйста, WB-MSW напрямую на БП, чтобы от WB-UPS работал только контроллер.
  3. Если есть возможность, физически извлеките модуль 4G. Если нет возможности извлечь, отключите его и не используйте.
  4. Смотреть нужно просто вывод с отладочного порта Отладочный порт — Wiren Board. Логиниться через него не нужно. Проверить, что вы смотрите то, что нужно, можно так: подключитесь по отладочному порту, не логиньтесь, параллельно зайдите по SSH и выполните reboot. Убедитесь, что в вывод отладочного порта попадают сообщения ОС, а затем сообщения от загрузчика.
#19

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

сделано

сделано. Вообще, странно. Я на этот упс планировал повесить еще 4 микротика… обрадовался было, что 24 вольтовые УПСы у вас.

Понял.

Вообще, я занялся настройкой node red, чтобы его нормально запустить пришлось удалить wb-z2m и еще пока вообще выключил zigbee для тестов. Уже 3й день ребутов не ловлю, как назло

#20

Спасибо!
Будем ждать перезагрузок.

Для WB-UPS v.2:
image

Для контроллера:
image

Для WB-MSW v.3:
image

Для WBIO-DI-WD-14:
image
Поэтому ваш расчёт правильный, мощности WB-UPS, разумеется, должно хватать. Просто сейчас у нас цель исключить все возможные факторы, даже маловероятные, чтобы точно определить причину перезагрузок.