Добрый день! При нажатии кнопки “Сохранить” в редакторе правил “колесико” крутится бесконечно долго (более 20 минут) и ничего не происходит, за исключением единственной записи в логе “INFO: reloading file: /etc/wb-rules/universal_heating.js”. Приходится делать рестарт сервиса wb-rules, после которого скрипт прогружается нормально. В чем может быть дело? Доступ к контроллеру предоставлен.
Здравствуйте! Я — автоматический помощник техподдержки Wiren Board.
Сейчас нерабочее время — я постараюсь помочь сразу, а в ближайший рабочий день
инженеры посмотрят тему и ответят.
Похоже, редактор дождаться завершения перезагрузки wb-rules, но сам движок при этом не возвращает ответ. По одной записи reloading file причину определить нельзя. Известно, что при изменении файла wb-rules автоматически перезагружает изменённый сценарий[1].
Пожалуйста, сообщите:
- Модель контроллера и релиз:
cat /etc/wirenboard-release - Вывод журнала сразу после нажатия «Сохранить»:
journalctl -u wb-rules -n 200 --no-pager - Не зависает ли именно
universal_heating.js: временно создайте копию правила с минимальным содержимым или сохраните другой небольшой файл и проверьте, повторяется ли проблема. Сам скрипт и используемые модули также желательно приложить.
В похожем случае на актуальных версиях WebUI уже встречалась проблема с отображением ошибок правил после сохранения, поэтому важны точная версия прошивки и полный журнал. До выяснения причины перезапуск wb-rules можно использовать как временный обходной путь.
Здесь может понадобиться мнение инженера Wiren Board. Для уверенного ответа мне может не хватить контекста — если можете, приложите логи или результаты тестов, я уточню гипотезы точнее.
Примечание: я — ИИ-ассистент, а не сотрудник-человек; в ответе возможны неточности. Если пришлёте уточняющие данные/логи, я смогу проверить гипотезы точнее.
root@wirenboard-AXCFBMYW:~# cat /etc/wirenboard-release
cat: /etc/wirenboard-release: No such file or directory
Файл /etc/wirenboard-release отсутствует — вероятно, в вашей версии прошивки используется другой способ определения релиза. Выполните, пожалуйста:
cat /etc/wb-release
Если файла тоже нет, пришлите вывод:
dpkg -l | grep -E 'wb-release|wb-rules|wb-homeui'
И журнал wb-rules после очередной попытки сохранения:
journalctl -u wb-rules -n 200 --no-pager
Пока по записи INFO: reloading file причину определить нельзя: нужно увидеть сообщения об ошибке или зависшем обработчике перезагрузки.
Здесь может понадобиться мнение инженера Wiren Board. Для уверенного ответа мне может не хватить контекста — если можете, приложите логи или результаты тестов, я уточню гипотезы точнее.
Примечание: я — ИИ-ассистент, а не сотрудник-человек; в ответе возможны неточности. Если пришлёте уточняющие данные/логи, я смогу проверить гипотезы точнее.
root@wirenboard-AXCFBMYW:~# cat /etc/wb-release
RELEASE_NAME=wb-2606
SUITE=stable
TARGET=wb8/bullseye
По выводу видно, что контроллер работает на WB8, релиз wb-2606. Само отсутствие /etc/wirenboard-release для этого образа нормально — нужная информация получена из /etc/wb-release.
Нашёл похожий случай: зависание после сохранения было связано с повторным созданием виртуального устройства в wb-rules, в частности с параметром lazyInit: true; в логе при этом появлялось сообщение trying to remove unexisting control[1]. Это не доказывает, что причина именно такая, но ваш симптом похож.
Проверьте, пожалуйста:
- Есть ли в
universal_heating.jsили подключаемых модуляхdefineVirtualDevice,lazyInit: true, а также создание устройств/контролов при каждом запуске правила. - Пришлите полный журнал после зависания:
journalctl -u wb-rules -n 200 --no-pager - Если в правиле есть
lazyInit: true, временно уберите этот параметр или сохраните минимальную копию правила без соответствующего виртуального устройства и проверьте, исчезает ли зависание.
Похожее поведение может быть связано с ошибкой в обработке перезагрузки правил в текущем релизе, поэтому для уверенного вывода нужен сам файл universal_heating.js и журнал. Здесь может понадобиться мнение инженера Wiren Board. Для уверенного ответа мне может не хватить контекста — если можете, приложите логи или результаты тестов, я уточню гипотезы точнее.
Примечание: я — ИИ-ассистент, а не сотрудник-человек; в ответе возможны неточности. Если пришлёте уточняющие данные/логи, я смогу проверить гипотезы точнее.
Добрый день!
Разбираюсь.
приложен диагностический архив, доступен только сотрудникам поддержки
(437,9 КБ)
Была еще похожая тема от меня
Проблему воспроизвёл на стенде с тем же релизом, что у вас: WB8, wb-2606 (stable), wb-rules 2.40.0-wb100, Debian 11.
Условие воспроизведения: правило создаёт виртуальное устройство с большим числом контролов (в моём тесте 500), и это правило сохраняется из редактора повторно. Первое сохранение проходит нормально, а на повторном движок правил встаёт: в журнале появляется
ERROR: [backend] trying to recreate control <устройство>/<контрол>, abort
после чего редактор не отвечает («колесико» крутится бесконечно), остальные правила тоже перестают работать, и помогает только перезапуск wb-rules - то есть в точности то, что вы описали. Воспроизводится нестабильно: у меня зависание случалось в 5 попытках из 6, при меньшем числе контролов (200 и меньше) - ни разу.
На релизе на базе Debian 13 с wb-rules 2.46.5 проблема не воспроизводится - ни при 500 контролах, ни при 2000. При этом старая версия wb-rules, установленная на Debian 13, зависает точно так же, то есть дело именно в версии wb-rules, а не в операционной системе или настройках контроллера.
Для линии релизов на Debian 11, к которой относится ваш wb-2606, обновления с изменённым поведением сейчас нет: версии, где проблема не проявляется, собраны только под Debian 13, и этот релиз пока находится в ветке testing. С выходом следующего стабильного релиза эта версия wb-rules станет доступна и в стабильной ветке и проблема уйдет с обновлением.
Технически перейти на ветку testing можно, но на работающей системе я этого не рекомендую: пакеты в testing не проходят полный цикл стабилизации, а обратный переход на stable не предусмотрен.
Пока исправление не вышло, работать можно так же, как вы уже делаете - перезапускать wb-rules после сохранения правила:
systemctl restart wb-rules
Честно говоря, есть некоторые сомнения, что дело именно в этом. Хотя, возможно, ход моих рассуждений не вполне верен:
Смущает то, что при сохранении скрипта и его загрузке в лог не попадает даже первая строка из файла. И даже в том случае, если фактическое создание каналов и правил отложены таймером на какое-то время.
Поправка к моему предыдущему сообщению: вывод о том, что на релизе на базе Debian 13 проблема не воспроизводится и уйдёт с обновлением, оказался преждевременным. Ваше сомнение было обоснованным - приношу извинения за неточность.
Разобравшись с вашим universal_heating.js, я собрал сценарий именно вашего случая. Каналы h00tempSensorOneErrorRule, h00tempSensorOneErrorTimer и аналогичные создаются функцией createDeviceChannel через addControl с параметром lazyInit: true, а значения в них записываются только при аварии датчика. Пока записи не было, канал в брокере не публикуется, и при перезагрузке файла движок пытается снять канал, которого в брокере нет. Вот что при этом происходит:
ERROR: [backend] trying to remove unexisting control zz_x/h00sensor14ErrorTimer
INFO: reloading file: /etc/wb-rules/zz_x.js
и дальше ничего: первая строка скрипта не выполняется, редактор не отвечает, правила не работают, загрузка процессора нулевая. Это в точности картина из вашего журнала, включая отсутствие первой строки, на которое вы обратили внимание.
Воспроизвёл это на трёх контроллерах: wb-2606 (Debian 11, wb-rules 2.40.0-wb100), wb-2609 из ветки testing (Debian 13, wb-rules 2.46.5) и на сборке из unstable (wb-rules 2.46.6). Во всех трёх случаого же повторного сохранения. Раньше я воспроизводилдругую стадию того же механизма - массовое пересоздание каналов, объявленных в cells; она на Debian 13 действительно не проявляется, и именно
это привело меня к неверному выводу.
Исходя из этого оформляю багрепорт.
Ну, главное - что разобрались с местом вероятной проблемы 
В части локализации проблемы - есть ли какое-то понимание сроков сего?
Выяснилось, что ранее (WB8 2407) уже чинили проблему с lazyInit.
Разработчики уже взяли в работу, точного срока пока не дадут - будет зависеть от нагруженности.
После исправления вас оповестим.
Два вопроса:
- Возможно ли предполагать возможность появления заплатки в течение ближайших двух недель?
- Она обычным порядком пойдет - сначала в testing и только позже - в stable?
Фикс уже выпустили и в ближайшее время он будет в тестинге.
В скором времени ожидаем выход нового стабильного релиза с этим исправлением.
В какой примерно временной рамке?
Конкретики не получил.
Более того, мое предположение выше было преждевременно, и с новым релизом исправленная версия какое-то время останется в тестинге.
Печально…
Что же тогда можем пока предпринять в части компенсирующих мероприятий?
Задал вопрос коллегам.
С вами свяжется коллега по эл. почте.