Редактор правил сломался

Сидел, экспериментировал с кодом, проверял работу скриптов…

Потом что-то произошло и в логах увидел:

27-01-2026 10:46:30.809 INFO: [engine] Starting sync loop
27-01-2026 10:46:30.808 INFO: the engine is ready
undefined -—
27-01-2026 10:46:30.808 INFO: [engine] Starting main loop
undefined -—
27-01-2026 10:46:30.777 INFO: [wbgo_mqtt] wb-rules-engine-wirenboard-XXX-2246539: MQTT connection established
undefined -—
27-01-2026 10:46:30.769 INFO: [rule info] using file /var/lib/wirenboard/wbrules-persistent.db for persistent DB
undefined -—
27-01-2026 10:46:30.767 INFO: driver is ready
undefined -—
27-01-2026 10:46:30.473 INFO: wait for driver to become ready
undefined -—
27-01-2026 10:46:30.472 INFO: driver loop is started
undefined -—
27-01-2026 10:46:30.468 INFO: [wbgo_mqtt] rules-wirenboard-XXX-2246539: MQTT connection established
undefined -—
27-01-2026 10:46:30.465 INFO: driver is created
undefined -—
27-01-2026 10:46:30.464 INFO: broker URL is default and mosquitto socket detected, trying to connect via it
undefined -—
27-01-2026 10:46:30.423 2026/01/27 10:46:30 ERROR: metrics: disable exposing PSI metrics because of failed init: open /sys/fs/cgroup/system.slice/wb-rules.service/cpu.pressure: no such file or directory
undefined -—
27-01-2026 10:46:28.624 github.com/wirenboard/wb-rules/wbrules/engine.go:1336 +0x218
undefined -—
27-01-2026 10:46:28.624 created by github.com/wirenboard/wb-rules/wbrules.(*RuleEngine).Start in goroutine 1
undefined -—
27-01-2026 10:46:28.624 github.com/wirenboard/wb-rules/wbrules/engine.go:863 +0x3a8
undefined -—
27-01-2026 10:46:28.624 github.com/wirenboard/wb-rules/wbrules.(*RuleEngine).mainLoop(0x400025f520)
undefined -—
27-01-2026 10:46:28.624 github.com/wirenboard/wb-rules/wbrules/engine.go:808 +0x278
undefined -—
27-01-2026 10:46:28.624 github.com/wirenboard/wb-rules/wbrules.(*RuleEngine).processEvent(0x400025f520, 0x4000553860)
undefined -—
27-01-2026 10:46:28.624 github.com/wirenboard/wb-rules/wbrules/engine.go:977 +0x100
undefined -—
27-01-2026 10:46:28.624 github.com/wirenboard/wb-rules/wbrules.(*RuleEngine).CallSync(0x400025f520, 0x400000f2d8)
undefined -—
27-01-2026 10:46:28.624 goroutine 66 [running]:
undefined -—
27-01-2026 10:46:28.624 panic: [engine] CallSync stuck!
undefined -—
27-01-2026 10:44:26.897 WARNING: [rule warning] DAC: no config file
undefined -—

/td>

В окне правил при этом крутится круглешок загрузки файлов

Как будто все мои скрипты куда-то пропали.

приложен диагностический архив, доступен только сотрудникам поддержки
(589,2 КБ)

Добрый день.

Высоковероятно в каком-то есть ошибка. Рекомендую все файлы скриптов переместить в другой каталог и проверить. Ну и копировать обратно по одному. Если обнаружите тот, на котором возникает ошибка - выложите сюда пожалуйста.

Я пытался заставить отправлять Emodjy и сделал 2 функции. Похоже, что в фукнции sendTelegramMessage

в строке

sendTelegramMessage("Failed to send message: " + response.description, “KEY”, -CHAT_ID);

я поймал рекурсию?

Вот код



global.proto.sendTelegramMessage = function(message, token, chatId) {
var encodedMessage = encodeURIComponent(message);
var requestBody = JSON.stringify({
chat_id: chatId,
text: encodedMessage,
parse_mode: ‘Markdown’
});
var command = “curl -s -X POST https://api.telegram.org/bot{}/sendMessage -H ‘Content-Type: application/json’ -d ‘{}’”;
//var command = “curl -s -X POST https://api.telegram.org/bot{}/sendMessage -d chat_id=-{} -d text=‘{}’ -d parse_mode=‘Markdown’ -d disable_notification=‘{}’”;

runShellCommand(command.format(token, requestBody), {
    captureOutput: true,
    exitCallback: function(exitCode, capturedOutput) {
        var response = JSON.parse(capturedOutput);
        if (response.ok) {
            log("Message sent successfully");
        } else {
            log("Failed to send message: " + response.description);
          sendTelegramMessage("Failed to send message: " + response.description, "KEY", -CHAT_ID); 
        }
    }
});

};

global.proto.SendTelegramTest = function(msg, silent) {
var request = “curl -s -X POST https://api.telegram.org/bot{}/sendMessage -d chat_id=-{} -d text=‘{}’ -d parse_mode=‘Markdown’ -d disable_notification=‘{}’”;
runShellCommand(request.format(“KEY”, “-CHAT_ID”, encodeURIComponent(msg.join(‘\r\n’)), silent || false),{
captureOutput: true,
exitCallback: function(exitCode, capturedOutput) {
var response = JSON.parse(capturedOutput);
if (response.ok) {
log(“Message sent successfully”);
} else {
log("Failed to send message: " + response.description);
sendTelegramMessage("Failed to send message!!!: " + response.description, “KEY”, -CHAT_ID);
}
}
});

// SendTelegramTest([“☑️ Проверка”, ‘Работает’], true);

SendTelegramTest([‘🏠 Проверка’, ‘Не отправляет’], false);

};

SendTelegramTest([‘Проверка’, ‘🔒⛔💧⚠️🔄’], false);

// Использование функции

//sendTelegramMessage(“Hello, world!⛔🔒⛔💧⚠️🔄⛔”, “KEY”, -CHAT_ID);
sendTelegramMessage(“Hello, world!⛔”, “KEY”, -CHAT_ID);

Удаление этого скрипта сильно облегчило состояние ЦПУ, был нагружен.

Я уже однажды поднимал тему в чате и возможно, на форуме… Что было бы неплохо конечно иметь с помощью имеющихся вочдогов и т.д. систему защиты от выстрела самому себе в ногу…

Мне вот эта картинка не оч нравится: mnt/data резко освободила место?

systemctl restart wb-rules

Выполнялась наверное минуты 2… не должно быть такого, я считаю….

Да, высоковероятно.
Я б пользовался готовым, например.

А как бы мог выглядеть механизм?

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

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

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

В случае со скриптом делать рестарт может быть тоже не лучшим вариантом (можно поймать цикл по ребут)

Возможно , я бы хотел видеть реализацию что вочдог смотрит каким-то образом за скриптом, и если он выполняется (или не отвечает) дольше ХХ мсек - то либо останавливает скрипт либо что-то ещё…

На самом деле это пример выше “как выстрелить в ногу” показывает недопустимость использования WB в критичных системах - например если бы у меня была включена электрикаменка (термостат на базе WB) в этот момент - она бы не выключилась….

Да, я осведомлен о необходимых функциях защиты “мимо контроллера” , но вижу как это работает на практике: к сожалению, даже промышленные контроллеры зависают, а датчики перегрева плохо прикручены и обогреватели сжигают системы HVAC промышленных цехов или отказывает система обнаружения пожара без какой либо индикации отказа….

Нет. Процесс один.

А есть ли пример реализации? Вот какая-нибудь система где так сделано?

Отнюдь. При проектировании как правило рассматривают любой вариант отказа. В том числе и зависания контроллера.