Сидел, экспериментировал с кодом, проверял работу скриптов…
Потом что-то произошло и в логах увидел:
/td> |
В окне правил при этом крутится круглешок загрузки файлов
Как будто все мои скрипты куда-то пропали.
Сидел, экспериментировал с кодом, проверял работу скриптов…
Потом что-то произошло и в логах увидел:
/td> |
В окне правил при этом крутится круглешок загрузки файлов
Как будто все мои скрипты куда-то пропали.
Добрый день.
Высоковероятно в каком-то есть ошибка. Рекомендую все файлы скриптов переместить в другой каталог и проверить. Ну и копировать обратно по одному. Если обнаружите тот, на котором возникает ошибка - выложите сюда пожалуйста.
Я пытался заставить отправлять 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);
Удаление этого скрипта сильно облегчило состояние ЦПУ, был нагружен.
Я уже однажды поднимал тему в чате и возможно, на форуме… Что было бы неплохо конечно иметь с помощью имеющихся вочдогов и т.д. систему защиты от выстрела самому себе в ногу…
systemctl restart wb-rules
Выполнялась наверное минуты 2… не должно быть такого, я считаю….
Да, высоковероятно.
Я б пользовался готовым, например.
А как бы мог выглядеть механизм?
Мне сложно компетентно сказать, так как я не очень силен в архитектуре скриптов. Это отдельный PID под каждый скрипт или как?
Мне кажется стоило бы этот вопрос вынести в отдельную ветку на самом деле, я касался уже этого вопроса ранее.
По базовой философии наверное вочдог должен следить за чем-то, что должно что-то успеть сделать - ну например классика, как и родной аппаратный и программной вочдог - если служба не ответила - делаем рестарт.
В случае со скриптом делать рестарт может быть тоже не лучшим вариантом (можно поймать цикл по ребут)
Возможно , я бы хотел видеть реализацию что вочдог смотрит каким-то образом за скриптом, и если он выполняется (или не отвечает) дольше ХХ мсек - то либо останавливает скрипт либо что-то ещё…
На самом деле это пример выше “как выстрелить в ногу” показывает недопустимость использования WB в критичных системах - например если бы у меня была включена электрикаменка (термостат на базе WB) в этот момент - она бы не выключилась….
Да, я осведомлен о необходимых функциях защиты “мимо контроллера” , но вижу как это работает на практике: к сожалению, даже промышленные контроллеры зависают, а датчики перегрева плохо прикручены и обогреватели сжигают системы HVAC промышленных цехов или отказывает система обнаружения пожара без какой либо индикации отказа….
Нет. Процесс один.
А есть ли пример реализации? Вот какая-нибудь система где так сделано?
Отнюдь. При проектировании как правило рассматривают любой вариант отказа. В том числе и зависания контроллера.