Архитектура интерпретатора скриптов RouterOS и ограничения выполнения

Начиная с RouterOS v7 (а также в ряде веток v6), встроенный планировщик задач (Scheduler) и обработчик сценариев (Scripting Engine) используют жесткие сторожевые таймеры (Watchdog Timers) для изоляции процессов управления от ядра маршрутизации. Событие script,error run failed: execution time limit exceeded возникает, когда синхронный скрипт превышает установленный квант процессорного времени (CPU Execution Quota / Script Timeout, по умолчанию от 20 до 120 секунд в зависимости от контекста вызова). Интерпретатор принудительно прерывает поток выполнения (Kill Thread), не сохраняя промежуточные переменные.

Бизнес-риски

Срыв регламентных сценариев: резервного копирования конфигураций (Backup/Export), обновления динамических списков блокировок (Address Lists / BGP Feeds), переключения резервных каналов провайдеров (Failover Scripts) и отправки телеметрии в Telegram/Zabbix.

Основные триггеры превышения лимита времени

Регламент оптимизации скриптов RouterOS

Сценарий 1: Замена тяжелых операций find на прямые выборки

Использование find внутри циклических итераций перегружает стек памяти. Заменяйте перебор прямым обращением по имени или фильтрацией:

# ПЛОХО: Алгоритмический тупик на больших таблицах
:foreach i in=[/ip firewall address-list find where list="BLOCK_LIST"] do={
    /ip firewall address-list remove $i
}

# ХОРОШО: Быстрое атомарное удаление через RouterOS CLI
/ip firewall address-list remove [find where list="BLOCK_LIST"]

Сценарий 2: Оптимизация резолвинга DNS и обработки внешних вызовов

Всегда перехватывайте ошибки и задержки сетевых команд с помощью конструкции :do { ... } on-error={ ... }:

# Безопасный скрипт опроса с ограничением таймаута
:local targetHost "backup.corp.local"
:local resolvedIP ""

:do {
    :set resolvedIP [:resolve $targetHost server=1.1.1.1]
} on-error={
    :log warning ("[DNS-Timeout] Failed to resolve " . $targetHost)
}

:if ($resolvedIP != "") do={
    :log info ("Host resolved: " . $resolvedIP)
}

Сценарий 3: Фоновое выполнение долгих задач через Scheduler

Если скрипт обязан выполнять долгую работу (например, парсинг логов или выгрузку бэкапа на удаленный FTP), разделите его на асинхронные порции или запускайте без ожидания завершения консоли:

# Запуск скрипта в изолированной среде фонового планировщика
/system scheduler add name="NIGHTLY_ASYNC_TASK" interval=24h start-time=03:00:00 \
    on-event="/system script run LongRunningProcess" policy=read,write,test

Типовые ошибки администраторов

• Помещение :delay 60s внутри синхронных триггеров: Использование длительных пауз внутри скриптов DHCP-Lease или Netwatch блокирует родительский процесс и вызывает немедленный kill по таймауту.
• Запуск бесконечных циклов :while (true): Блокирует поток выполнения скриптового движка; регулярные задачи должны управляться исключительно через /system scheduler.