Версия 2.6.3.
Второй раз встречаю такое. У меня идет управление узлом, критичным к шагу, на котором находится стейт-машина, и такие спорадические рестарты могут тупо его угробить.
Скажите, ПОЖАЛУЙСТА, что именно не нравится данному “чеку” спорадически раз в пару-тройку суток?! И обязательно ли, черт подери, перегружать движок? Похоже, год назад вы проигнорировали мой совет выгнать из команды виндузятника и он по-прежнему подгаживает в малозаметных местах.
Здравствуйте!
Скажите, ПОЖАЛУЙСТА, что именно не нравится данному “чеку” спорадически раз в пару-тройку суток?!
В сервисе cron стоит задача раз в пять минут сравнивать время Uptime, которое отображается в веб-интерфейсе контроллера и которое обновляется движком правил, и время Uptime, которое было при предыдущем запуске cron. Установлена ли задача можно проверить командой crontab -e. Вывод команды с установленной задачей:
*/5 * * * * /usr/share/wb-daemon-watchdogs/check_wbrules.sh 2>&1 | logger -t wb-daemon-watchdogs
Задача 1 раз в пять минут вызывает на исполнение файл /usr/share/wb-daemon-watchdogs/check-wbrules.sh, где и происходит проверка времен и перезапуск движка правил.
Если эти времена совпадают, то делается вывод, что сервис wb-rules не работает и происходит его автоматический перезапуск.
И обязательно ли, черт подери, перегружать движок?
Конечно, можно отключить эту задачу в демоне cron, но тогда при зависании движка wb-rules он уже не запуститься автоматически. То есть похоже на то, что движок у вас перестает работать раз в несколько суток и автоматически перезапускается.
Есть ли какие-нибудь сообщения в логах об ошибках? Недавно в движке правил было сделано несколько исправлений, попробуйте его обновить до последнего из ветки testing (v 2.8.0).
Вы, коллеги, меня извините заранее, буду эмоционален, поскольку проблема для меня смыслообразующая. Не хочу никого обидеть или задеть. Думал, повторять это не надо. А надо.
- КОНТРОЛЛЕР ДОЛЖЕН ВЕСТИ СЕБЯ ПРЕДСКАЗУЕМО. В противном случае в мануале первой строкой красным цветом должно быть написано: это ИГРУШКА и это не предназначено для УПРАВЛЕНИЯ устройствами.
- Ребут НЕ ЛЕКАРСТВО, я это очень громко орал здесь год назад. Здесь не винда, ребутом ничего исправить не получится!!! Если демон/скрипт нестабилен, надо искать и корчевать ПРИЧИНУ. Сам линух превосходно работает десятилетиями без каких-либо вочдогов.
- Вся подробная информация об осыпавшемся демоне или скрипте ОБЯЗАНА быть в логах. Что именно и как полетело. При возможности - еще и почему.
- Тихонько передернуть демон, который занимается УПРАВЛЕНИЕМ - смерти подобно, это подход, ПРИНЦИПИАЛЬНО недопустимый для контроллера, который обязан спокойно молотить годами и десятилетиями. Такая практика ставит КРЕСТ на перспективах сколь-нибудь серьезного рыночного применения изделия. Вы понимаете, что, в отсутствие ЯВНЫХ упоминаний о подобных косяках в документации, кто-нибудь сможет открыть газ в котел, а запальником чиркнуть через час?!!
Ребут - НЕШТАТНАЯ, АВАРИЙНАЯ, ЭКСТРЕННАЯ ситуация, о которой надо ВОПИТЬ во все колокола, а не оставлять строчку в логе, что, дескать, упс, время не совпало.
В общем, я жду исчерпывающей инфы на данную тему. И решаю дальше, сворачивать мне программу установки ваших контроллеров, или продолжать вычесывать баги.
Наткнулся, похоже, на упомянутое вами “зависание” wb-rules. Вочдог выкорчевал, наблюдал несколько часов, “повезло”.
Движок не висит, в топики кладет таймстемпы (у меня на сервере обработчик потери контроллера), в лог рапортует, но релейками не щелкает. После service restart - заработало.
Однако, очень сырой движок… Можно ли его попросить класть в логи инфу о собственном здоровье?
Да, вот это решение с контролем “аптайма” - оно историческое. Надо делать контроль стандартным способом - по файлику с пидом в /run и обрабатывать отсутствие процесса штатными средствами ОС.
Ага, то есть не пишет (и не читает) MQTT, получается, а сам по себе работает.
А что за скрипт?
Водоснабжение дома, на минуточку. Там сотен пять строк на все файлы.
Раз уж вы таки решили мне ответить, пара доп. вопросов:
- Влияют ли на wb-rules падения и подъемы сетевого интерфейса? У меня есть сильные подозрения, что ДА.
- Если я перестартовываю wb-mqtt-serial, но не перестартовываю wb-rules, может ли быть такое, что второй не цепляется за первый? В таком случае вышеописанная ошибка понятна, в противном - нет.
Вообще бы ОЧЕНЬ неплохо документировать зависимости! Например, у меня скрипты должны стартовать в определенном порядке - достаточно ли поименовать js файлы по алфавиту?
Ни в коем случае. Раззнакомлюсь.
Необходимо иметь несколько логлевелов, задаваемых в конфиге (none/err/warn/info/debug) и рассказывать пользователю, что стряслось.
Добрый день!
Очень извиняемся, что вам пришлось столкнуться с такими проблемами.
Если вы не возражаете, я бы предложил подключить к вашей проблеме нашего программиста, который занимается исправлениями в wb-rules в последнее время. Есть нюанс: он сейчас в отпуске, но смог бы подключиться по AnyDesk на этой неделе в день по договорённости.
Будет ли у вас такая возможность? Если да, пожалуйста, пришлите мне личным сообщением ваш контакт для оперативной связи (аккаунт телеграм или номер телефона).
Перед этим очень желательно сделать следующее:
- Понять, на каком вы сейчас релизе, stable или testing: Релизы ПО Wiren Board — Wiren Board
- Обновить wb-rules на последнюю версию для вашего релиза.
- Проверить, что проблема всё ещё воспроизводится.
- По возможности найти способ гарантированно воспроизводить проблему.
Да нормально все, лишь бы не было разных обидок. Вы делаете отличное железо! Мне пока за год с лишним не удалось убить ни один модуль (3тьфу). Это - показатель. Но с софтом у вас очень часто проскакивает индокитайское наплевательство - аааа, ребутнем, авось попустит.
ТАК - НЕЛЬЗЯ, это может порушить “khu yam” вам весь бизнес. Проходили.
Не попустит. Контроллер ОБЯЗАН быть надежным как топор. Прошу это впитать и никогда не упускать из виду.
- Убирайте вочдоги по пидам. Вообще! Кому их надо, или кто прогать не умеет - сам поставит. Я оставил один вочдог - по железному зависанию - и даже он за год пока не выстрелил, хотя контроллер в одном шкафу с частотником и пускачом ставить приходилось.
- 6.6.0D 409, wirenboard-AGPLM2T7 4.9.22-wb6 #2 SMP Tue Mar 9 09:47:37 UTC 2021 armv7l GNU/Linux, wb-rules 2.6.3.
Апгрейд дистра не делал, ибо отойти от управления не получится надолго, узел в бою. Сейчас вот попробовал на тестовом приборе, а там, непечатно, снова сервис вочдога откопался и попер его ребутать по циклу… - Да, как накачаю резервуар.
- Как??? )))) Если она спорадическая by nature. Лучше уже давайте логи начнем писать с wb-rules, иначе это переливание пустоты, и я лучше овна какого-нибудь туда воткну, чем жечь тонны времени впустую.
Вообще, иметь вменяемые логи для каждого демона - это одно из первых правил нормального прогера, не-се па?
Второй раз проблема, очень похоже, вызвана этой причиной.
Просьба комментировать.
Вообще - как и wb-mqtt-serial так и wb-rules напрямую друг с другом не взаимодействуют, то есть никак. Все общение - через топики MQTT. Но вот при перезапуске serial, тот пересоздает топики своих устройств. Вот тут может быть что, при пересоздании значение какого-то, свежесозданного топика стало null (вообще нормальное поведение) перед тем как в него записалось считаное значение.
То есть механизм работы serial:
- запустился, прочитал конфиг.
- создал топики устройств
- прочитал устройства - занес данные в топики, далее в цикле.
То есть, возможно, бага в обработке пропадания (пересоздания) топиков, попробую написать правило и поперезапускать serial. Или синтетически - создавать топики скриптом.
Ну вот тут тонкое место для взаимных dependencies, а где тонко, там и рвется.
Предлагаю в кратчайшие сроки сделать нормальные ЛОГИ для каждого демона (неужели действительно не сделано? Я, например, начинаю с этого) и я, поставив максимальный уровень подробности, начну вычесывать все эти нестыковки.
И даже денег (пока) не попрошу. Потом набьюсь в долю. Пока же дело сделать нужно. ОЧЕНЬ всё сырое, други…
ОЧЕНЬ всё сырое, други…
Некоторые пользователи данных контроллеров (и я в том числе) давно “забили” на wb-rules и пишут основную часть кода (обработка данных с датчиков и управление исполнительными устройствами) на Python, Perl, С и даже на Shell. Получается на порядок надежней и предсказуемым, потому как сама платформа (Linux и его окружение) давно отлажены и на практике доказали свою надежность. Я лично wb-rules использую как часть WebUI для подготовки и вывода информации + быстрая автоматизация менее значимых процессов.
Я потихоньку ближусь к такому же решению…
Но, согласитесь, идея-то была отличная, если б не подвела реализация. Так-то львиная доля задач спокойно решается банальной ардуинкой, - если нет цели собрать красивую и довольно могучую платформу.
Будем надеяться, что платформа таки преодолеет статус первой (самой трудной) беты и продолжит свой путь к релизу.
Сегодняшней ночью wb-rules молча вывалился (вочдог я ранее убрал).
Молча. Вывалился. На третьи сутки работы. В логах пусто.
Вот така фигня, малята.
Пойду овна куплю на этот узел, фигли.