Ошибка в сервисе wb-mqtt-serial


#1

Добрый день.

Вот с чем столкнулся сегодня:
root@wirenboard-ARAXKJYF:~# service wb-mqtt-serial status
[FAIL] wb-mqtt-serial is not running … failed!
root@wirenboard-ARAXKJYF:~# service wb-mqtt-serial restart
[…] Restarting MQTT Driver for Serial devices: wb-mqtt-serialstart-stop-daemon: warning: failed to kill 3374: No such process
. ok

Полагаю, что очередной раз натыкаюсь на незавершённый процесс SetTimeout или в чем дело? Можно по этой информации понять что произошло? Restart сервиса помог, но хотелось бы избежать подобной ситуации. Может автоматический рестарт возможно сделать, проверяя службу через Cron?


#2

А в логах пусто?


#3

Вот последнее, что имеет отношение к Serial:

Jun 30 01:15:38 wirenboard-ARAXKJYF user.notice serial: ModbusRTU::ReadRegisterRange(): failed to read 16 coil(s) @ 0 of device modbus_io:185:3: Serial protocol error: request timed out
Jun 30 01:15:40 wirenboard-ARAXKJYF user.notice serial: Init: IODIR: setup register <modbus_io:185:3:: 10000> <-- 0
Jun 30 01:15:40 wirenboard-ARAXKJYF user.notice serial: Init: IPOL: setup register <modbus_io:185:3:: 10001> <-- 0
Jun 30 01:15:40 wirenboard-ARAXKJYF user.notice serial: Init: GPINTEN: setup register <modbus_io:185:3:: 10002> <-- 65535
Jun 30 01:15:40 wirenboard-ARAXKJYF user.notice serial: Init: DEFVAL: setup register <modbus_io:185:3:: 10003> <-- 0
Jun 30 01:15:40 wirenboard-ARAXKJYF user.notice serial: Init: INTCON: setup register <modbus_io:185:3:: 10004> <-- 0
Jun 30 01:15:40 wirenboard-ARAXKJYF user.notice serial: Init: IOCON: setup register <modbus_io:185:3:: 10005> <-- 17476
Jun 30 01:15:40 wirenboard-ARAXKJYF user.notice serial: Init: FLAG: setup register <modbus_io:185:3:: 9999> <-- 1
Jun 30 01:19:57 wirenboard-ARAXKJYF user.notice serial: FATAL: Serial protocol error: can’t write to discrete. Stopping event loops.

До этого события я вручную через WEB интерфейс выключил свет, который не погас по таймеру. Больше ничего не совершал, а утром обратил внимание, что устройства ввода-вывода не реагируют, но правила живы и виртуальные контролы тоже отвечали.


#4

Starck, а какая у вас топология RS-485? Кроме WB-MIO с адресом 185 есть что-то? После падения wb-mqtt-serial, до перезагрузки, вы через modbus_client можете опросить WB-MIO, например? Или другие устройства на шине?


#5

Добрый день!
wb-mqtt-serial никак не связан с SetTimeout.
Судя по

вы, возможно из движка правил, пытаетесь писать в read-only регистр.


#6

Есть, вот тут:


#7

Да нет же, все как у вас в примерах. Вот правила, которые работают с mio 185


#8

Bp кода не видно, что могло бы приводить к такой ошибке. Однако, поскольку у вас имена контролов формируются на лету, я бы включил отладку и вставил для начала хотя бы логгирование вызова правил, чтобы определить, в каком правиле происходит сбой, а затем бы смотрел, каким именно устройствам/контролам вы пытаетесь присвоить значение.


#9

Сейчас как на зло, это может долго не наступить, а лучше бы никогда в идеале. А как выявить падение этого сервиса? Если правила не упали, то можно отправить сообщение о сбое serial ? Должна же быть Команда возвращающая статус сервиса. Так можно все сервисы проверять и уведомлять о проблемах своевременно.


#10

Прямо из коробки решения нет, можно по крону запускать скрипт типа
pgrep wb-mqtt-serial >/dev/null && echo "OK" || echo "ERR"

Вместо echo "ERR" отправлять e-mail, скажем. Такой легковесный мониторинг.


#11

Написал правило, может кому интересно.

//проверка работы сервисов
defineRule(“Services_Status_Control”, {
when: cron("@every 6h"), // выполняется 4 раза в сутки
then: function () {
runShellCommand(“pgrep wb-mqtt-serial >/dev/null && echo ‘Check wb-mqtt-serial service: [STATUS OK]’ || echo ‘Check wb-mqtt-serial service: [STATUS FAILED]’ | ssmtp user@gmail.com”);
}
});

А как подставить сюда тему Сообщения или то же самое отправлять на телефон?


#12

Для ssmtp удобно заголовок в файле сформировать, с темой и прочим: https://unix.stackexchange.com/questions/244294/how-to-add-subject-line-when-sending-email-output-of-find-using-ssmtp

На телефон – через gammu:
https://wirenboard.com/wiki/index.php/GSM/GPRS#SMS_.D0.B8_USSD_.D0.BD.D0.B0_.D1.80.D1.83.D1.81.D1.81.D0.BA.D0.BE.D0.BC


#13

Слышал щелчок реле и в интерфейсе устройства стали неактивны на пару секунд. Вот что в логе:
ModbusRTU::ReadRegisterRange(): failed to read 16 holding(s) @ 250 of device modbus_io:185:2: Serial protocol error: request timed out

ModbusRTU::ReadRegisterRange(): failed to read 8 coil(s) @ 0 of device modbus_io:191:2: Serial protocol error: request timed out
Jul 4 01:22:38 wirenboard-ARAXKJYF user.notice serial: Init: IODIR: setup register <modbus_io:191:2:: 10000> <-- 0
Jul 4 01:22:38 wirenboard-ARAXKJYF user.notice serial: Init: IPOL: setup register <modbus_io:191:2:: 10001> <-- 0
Jul 4 01:22:38 wirenboard-ARAXKJYF user.notice serial: Init: GPINTEN: setup register <modbus_io:191:2:: 10002> <-- 65535
Jul 4 01:22:38 wirenboard-ARAXKJYF user.notice serial: Init: DEFVAL: setup register <modbus_io:191:2:: 10003> <-- 0
Jul 4 01:22:38 wirenboard-ARAXKJYF user.notice serial: Init: INTCON: setup register <modbus_io:191:2:: 10004> <-- 0
Jul 4 01:22:38 wirenboard-ARAXKJYF user.notice serial: Init: IOCON: setup register <modbus_io:191:2:: 10005> <-- 17476
Jul 4 01:22:38 wirenboard-ARAXKJYF user.notice serial: Init: FLAG: setup register <modbus_io:191:2:: 9999> <-- 1

События произошли в разное время и устройства подключены к своим MIO, объединенных между собой одной шиной.
В первом случае это устройство WBIO-DI-DR16, а во втором: WBIO-DO-R10R-4. Правила не выполнялись, до этого я делал рестарт у mqtt-serial


#14

Strack, добрый день!
А после этого все заработало снова без вашего вмешательства?


#15

Именно. Может из-за помех на линии RS-485 все это происходит? Кто инициирует чтение регистров, если правила молчат? И почему они ошибку выдают? Такое ощущение, что запросы генерируются случайным образом. Отсюда и попытка записи в DI, описанная в начале поста.


#16

Линию опрашивает wb-mqtt-serial, он же пишет в регистры. Ошибка на линии вполне возможна. Запросы генерируются в циклической очереди, последовательно, с отработкой ошибок, записи в регистр ставятся вне очереди после окончания очередного запроса. Если ошибки повторяются относительно часто, то надо поставить у порта в Web-интерфейсе флажок отладки и смотреть, какие сообщения будут приходить от wb-mqtt-serial в /var/log/messages.


#17

Хорошо, понаблюдаю. Хотите ли Вы сказать тем самым, что это нормальная практика и переживать не стоит? или все же это сказывается на работе устройств как правило и надо разбираться? Мне Евгений ваш рекомендовал еще в прошлом году землю всех MIO объединить для уменьшения помех. Видимо и с этим придется поработать для понимания истинных причин в сбоях.


#18

Ну, переживать точно не стоит, надо разобраться, когда происходят эти сбои: при коммутации мощной нагрузки? Объединить GND всех устройств, подключенных к порту – хорошая практика, думаю, это стоит сделать.