Перезапуск интерфейса при его отключении

Да, сложная часть (если использовать не «простой» netwatch, а более новую и мощную ICMP-пробу) — найти правильные настройки для срабатывания (или не срабатывания) скрипта «down». Смотри: @amm0 Если я всё правильно понимаю, у netwatch есть явное преимущество перед обычным расписанием — скрипт «down» запускается только при смене статуса с «up» на «down», тогда как с обычным расписанием сначала пришлось бы проверять, не разорвано ли уже соединение. Иначе, если отключение/включение не сработает (или если соединение перестало работать по другой причине), интерфейс будет циклично отключаться и включаться примерно каждые 20 секунд, пока связь не восстановится (если вообще восстановится).

Верно, скрипт netwatch запускается только при смене состояния. То есть при переходе с up на down скрипт вызывается. Если следующий тест не прошёл, и предыдущий тоже не прошёл, скрипт не вызывается. Это тоже верно. Вот в чем принципиальная разница: в скрипте /system/schedule ты и определяешь состояние, и принимаешь решение, и отслеживаешь, что уже сделано. В netwatch ты можешь сосредоточиться на действиях и использовать GUI (возможно с сложными переменными) для настройки своих «правил». Единственный момент с up-script={} и down-script={} в netwatch — возможны «флапы», особенно при проверке icmp, поскольку состояния «up» и «down» могут переключаться из-за задержек или других частично разорванных соединений. Это может быть либо некорректной или слишком агрессивной настройкой netwatch, либо просто плохим интернетом (тест правильный), и тогда, если не хочется перезагружать, с netwatch на одном только «up» и «down» от одного теста начинает быть сложнее. В этом плане есть ещё опция test-script={}, которая работает как /system/schedule, но по интервалу netwatch. При этом она даёт результат последнего теста, то есть у тебя уже есть данные (в отличие от «чистого» scheduled script, где нужно самому считать, up или down). А если нужно отслеживать несколько условий до принятия решения, это становится чуть сложнее. В scheduler можно добавить ещё много :if и :global lastValueXxxx. В netwatch же приходится использовать один скрипт как «мастер» с test-script=, который в своём коде читает значения других активных netwatch-мониторов с дополнительными тестами, чтобы добиться некоего netwatch «парлея» (то есть нескольких значений, которые должны быть одновременно true или false, чтобы выполнить действие).

Зависит от ситуации: можно использовать свой скрипт в качестве “down” скрипта в netwatch или вызывать свой скрипт из “down” скрипта. Netwatch — это всего лишь (или может быть только) механизм срабатывания, при этом, как уже объяснялось, он имеет некоторые преимущества перед альтернативой — “обычным” планировщиком заданий. Пользовательский скрипт — независимо от того, какой механизм его запускает — может выполнять дополнительные проверки перед отключением и включением интерфейса (чтобы избежать ложных срабатываний), а если использовать его через планировщик, в скрипте должны быть предусмотрены меры для предотвращения циклов отключения/включения.

В Netwatch, когда пинг не проходит, запускается скрипт отключения. Что происходит, когда пинг снова начинает работать?