remove [find] зависает во время выполнения

У меня есть 11 одинаковых коммутаторов, и все они зависают в одном и том же месте (/interface/bridge и /ip/dhcp-server), так что нет, это не проблема конкретного оборудования.

Это происходит в /system/script или через CLI? Если через CLI, то локальная переменная исчезает при следующем приглашении — поэтому она равна nil [:nothing]. Тебе нужно использовать фигурные скобки в CLI: /interface/bridge/vlans { :local x [find]; remove $x } Возможно, стоит уточнить команду “find”, потому что в скриптах иногда бывают странности. Например, если ты имеешь в виду /interface/bridge/port/find… тогда используй полную форму, чтобы проверить, сработает ли это.

Зависание просто странное. Если тот же скрипт работает на ARM, то похоже на ошибку. Использовать :local в :import скрипте без фигурных скобок, возможно, разрешено или работает, но я так не советую. А если просто ввести :put [/interface/bridge/find] в CLI, тоже зависает? Единственное, что можно попробовать — добавить какое-то условие к find, например [find name~“*”], чтобы выбирать все имена. Возможно, нужен какой-то фильтр — вроде бы не должен, но это может помочь избежать зависания (или по крайней мере дать дополнительную информацию для отчёта об ошибке).

Спасибо за ваше мнение. Возможный контраргумент к этой теории в том, что если бы причиной был именно недостаток места, то я ожидал бы последовательного и предсказуемого поведения — как только место заканчивается, скрипт всегда должен бы зависать. Однако я замечаю, что это происходит только иногда, а не постоянно. Тем не менее, сейчас я собираюсь проверить эту теорию, полностью очистив устройство (форматируя хранилище) с помощью NetInstall, чтобы посмотреть, исчезнет ли проблема на какое-то время после этого. Отпишусь о результатах.

Хорошо, думаю, я двигаюсь в правильном направлении. По крайней мере, теперь я могу воспроизвести проблему детерминированно.  

Шаги воспроизведения (для удобства я автоматизировал большую часть из них в скрипте в конце сообщения):  
- Нужно использовать коммутатор CRS354-48P-4S+2Q+ на базе MIPS (на роутерах с ARM64 проблему не воспроизвести).  
- Подключиться к устройству через MGMT Ethernet порт (ether49) с помощью WinBox.  
- Создать пользовательский список интерфейсов и добавить в него все 48 Ethernet-портов как участников списка (это можно автоматизировать в скрипте). Не включайте ether49 в этот список, если не хотите, чтобы ваше соединение в WinBox сбрасывалось на следующем шаге.  
- Создать бридж и добавить ранее созданный список интерфейсов в список портов бриджа (это также можно автоматизировать).  
- Открыть GUI-диалог /System/Resources для мониторинга загрузки CPU (нет, гаджет нагрузки CPU на дашборде WinBox не отражает реальную нагрузку, так что пользуйтесь именно этим диалогом!).  
- Убедиться, что загрузка CPU в GUI-диалоге не 100%. Если 100%, не продолжайте, пока не снизится.  
- Запустить скрипт, который за один проход: сначала удаляет все не динамические элементы из /interface/bridge/port, а затем удаляет все элементы из /interface/bridge:  
```
:put "Resetting device configuration"
# Очищаем все списки
:put " Clearing bridge port list"
/interface/bridge/port
:local ids [find where !dynamic]
remove $ids
:put " Clearing bridge list"
/interface/bridge
:put "  1"
:local ids [find]
:put "  2"
remove $ids
:put "  3"
```
Скрипт зависнет во второй части (удаление всех элементов из /interface/bridge). Точнее, он зависает на попытке найти все эти элементы.  

Наблюдаем нагрузку CPU — она будет 100%.  
Прервите скрипт комбинацией Ctrl-C.  
Нагрузка CPU останется 100% еще несколько минут.  

Не дожидаясь снижения загрузки CPU, запустите скрипт снова — он снова зависнет на том же месте — при попытке прочесть список /interface/bridge/. Так будет каждый раз, пока CPU загружен на 100%.  

Прервите скрипт Ctrl-C.  
Сходите за чаем или кофе, подождите, пока нагрузка CPU упадет с 100% до нормальных значений. Это займет несколько минут.  

Запустите скрипт еще раз — на этот раз он не зависнет. Разница в том, что теперь в первой части скрипта нечего удалять из /interface/bridge/port, поэтому CPU не загружается и скрипт спокойно доходит до второго шага, где уже не зависает.  

Вывод: для зависания скрипта нужна такая комбинация:  
- Нагрузка CPU из-за удаления одного не динамического элемента типа списка из /interface/bridge/port, что вызывает автоматическое удаление 48 динамических элементов.  
- Немедленный вызов /interface/bridge [find], который и зависает.

Важные моменты:  
- Если /interface/bridge/port уже пуст, всплеска нагрузки CPU не будет, и скрипт не зависнет.  
- Также обратите внимание, что при наличии элементов в /interface/bridge/port удаление возвращается сразу и успешно, а соответствующее GUI-окно сразу показывает исчезновение всех элементов (как статических, так и динамических), но CPU остается перегруженным еще некоторое время и не может корректно обработать последующие операции.  
- На самом деле, даже скрипт не нужен, чтобы воспроизвести эту перегрузку CPU — можно просто удалить один не динамический элемент из /interface/bridge/port в GUI и посмотреть, как CPU уйдет в 100% загрузку на следующие две минуты без видимой причины (хотя все элементы из списка, и динамические, и статические, исчезают моментально).  

Вот объединённый скрипт, который воспроизведёт и настройку, и проблему (при первом запуске он не зависнет, так как сначала очищает, а потом настраивает, так что запускайте его дважды).  

```
# [ Конфигурация ]
:local ConfigDoClean 1;
:local ConfigDoLAN 1;

# [ Данные для поиска ]
:local PortListLAN {
"ether1"; "ether2"; "ether3"; "ether4"; "ether5"; "ether6"; "ether7"; "ether8";
"ether9"; "ether10"; "ether11"; "ether12"; "ether13"; "ether14"; "ether15"; "ether16";
"ether17"; "ether18"; "ether19"; "ether20"; "ether21"; "ether22"; "ether23"; "ether24";
"ether25"; "ether26"; "ether27"; "ether28"; "ether29"; "ether30"; "ether31"; "ether32";
"ether33"; "ether34"; "ether35"; "ether36"; "ether37"; "ether38"; "ether39"; "ether40";
"ether41"; "ether42"; "ether43"; "ether44"; "ether45"; "ether46"; "ether47"; "ether48";
};

# [ Сброс ]
:if ($ConfigDoClean) do={
:put "Сброс конфигурации устройства"
# Очистка всех списков
:put " Очищаем список портов бриджа"
/interface/bridge/port
:local ids [find where !dynamic]
remove $ids
:put " Очищаем список бриджей"
/interface/bridge
:put "  1"
:local ids [find]
:put "  2"
remove $ids
:put "  3"
:put " Очищаем список интерфейсов"
/interface/list
:local ids [find where !builtin]
remove $ids
:put " Очищаем список участников интерфейсов"
/interface/list/member
:local ids [find]
remove $ids
};

# [ Настройка LAN ]
:if ($ConfigDoLAN) do={
:put "Настройка LAN"
# Настройки портов/интерфейсов
:put " Настраиваем список интерфейсов LAN"
/interface/list
add name=InterfaceList.LAN
/interface/list/member
:foreach Port in=($PortListLAN) do={
add interface=$Port list=InterfaceList.LAN
}
:put " Настраиваем LAN бридж"
/interface/bridge
add name=Interface.LAN
/interface/bridge/port
add bridge=Interface.LAN interface=InterfaceList.LAN
};
 
На этом этапе я сделал всё, чтобы максимально надежно воспроизводить проблему, думаю, теперь пора кому-то из MikroTik исправлять это, как только закончится Лиго.

Хорошо, как и обещал, я попробовал полностью очистить устройство с помощью NetInstall — видел, как программа сообщала «форматирование жесткого диска», а затем устанавливала последнюю версию RouterOS (7.15.1). Потом запустил скрипт, который приводил в предыдущем сообщении — и он снова зависает уже с первой попытки. Так что нет, дело не в «остатках» в файловой системе. Это что-то, что по-настоящему перегружает процессор каждый раз.

Возможно, есть какой-то механизм блокировки, который работает не совсем правильно. Конечно, можно считать это багом, и было бы здорово сообщить об этом через систему тикетов. Если первая команда вызывает загрузку процессора, которая продолжается даже после завершения выполнения команды, по крайней мере, ПО должно ждать её окончания, прежде чем запускать следующую команду. Всё равно удивительно, что это занимает так много времени, но, по крайней мере, система не должна действительно зависать.

При этом не забывайте, что у этих процессоров довольно низкая производительность. Сам коммутатор может работать на максимальной скорости, потому что это делает аппаратное обеспечение, но CPU явно не подходит для обработки такого большого количества элементов — их целых 48. Разработчики, вероятно, предполагали, что подобные действия не будут выполняться регулярно. И, скорее всего, так и надо.

Я могу представить, что вы столкнулись с этим, когда у вас несколько таких коммутаторов и вы хотите изменить конфигурацию сразу на всех, чтобы привести их к каким-то новым требованиям, и написали для этого хитрый скрипт. Но в обычной работе делать так не стоит. То есть, например, не стоит планировать такую настройку, если вам нужно будет делать это каждый день.