Перезагрузить контроллер или перезапустить NetworkManager.
В журнале появляется событие device-reapply/reapply, затем предупреждение dispatcher и таймаут (~25 s):
... audit: op="device-reapply" interface="eth0" ifindex=3 args="ipv4.route-metric" ...
... dhcp4 (eth0): state changed new lease, address=192.168.2.54
... dispatcher: (11) /etc/NetworkManager/dispatcher.d/01-ifupdown failed (failed): Script '/etc/NetworkManager/dispatcher.d/01-ifupdown' exited with status 1.
... failed (after 24.667 sec): Failed to activate service 'org.freedesktop.nm_dispatcher': timed out (service_start_timeout=25000ms)
Почему это проблема
При возврате кода 1 dispatcher помечает скрипт как failed и ждёт завершения nm-dispatcher (service_start_timeout ≈ 25000 ms), что удлиняет запуск/переключение сетевых интерфейсов и может приводить к дополнительным проблемам (unmanaged деактивации и т.п.).
Скрипт имеет shebang #!/bin/sh -e — любой ненулевой код команды приведёт к немедленному выходу со статусом 1. Даже если логика внутри case содержит no‑op, возможен путь исполнения, где тест/выражение даёт ошибку. Проще и безопаснее явно вернуть 0 для действий reapply/device-reapply до выполнения любой логики.
Предлагаемое исправление (вставить ранний no‑op + exit 0 для reapply и device-reapply)
Патч делает обработку reapply/device-reapply явной и ранней — немедленный успешный выход, чтобы гарантированно не возвращать ненулевой код.
Unified diff (применяется к /etc/NetworkManager/dispatcher.d/01-ifupdown):
--- a/01-ifupdown 2025-02-25 00:00:00.000000000 +0000
+++ b/01-ifupdown 2025-02-25 00:00:00.000000000 +0000
@@
-#!/bin/sh -e
+#!/bin/sh -e
# Script to dispatch NetworkManager events
#
# Runs ifupdown scripts when NetworkManager fiddles with interfaces.
# See NetworkManager(8) for further documentation of the dispatcher events.
+
+# Early-exit for reapply/device-reapply to avoid accidental non-zero exit codes
+# when NetworkManager only updates some settings. This prevents dispatcher
+# from treating the script as failed and avoids long dispatcher timeouts.
+if [ "$2" = "reapply" ] || [ "$2" = "device-reapply" ]; then
+ exit 0
+fi
Применение патча на контроллер (если нужно локально проверить):
sudo cp -a /etc/NetworkManager/dispatcher.d/01-ifupdown /etc/NetworkManager/dispatcher.d/01-ifupdown.bak
sudo sed -i '1a\
\
# Early-exit for reapply/device-reapply to avoid accidental non-zero exit codes\
if [ "$2" = "reapply" ] || [ "$2" = "device-reapply" ]; then\
exit 0\
fi' /etc/NetworkManager/dispatcher.d/01-ifupdown
sudo chmod 755 /etc/NetworkManager/dispatcher.d/01-ifupdown
sudo systemctl restart NetworkManager
(я уже пробовал аналогичный workaround локально — он устраняет предупреждение dispatcher и таймаут)
Просьба от пакета (что ожидаем)
Внести фикс в пакет network-manager (или дистрибутивный wrapper), чтобы штатный /etc/NetworkManager/dispatcher.d/01-ifupdown корректно и безопасно обрабатывал action’ы reapply/device-reapply (ранний возврат 0) и выпустить обновление.
Опционально: проверить пути в скрипте, где могут возникнуть ненулевые возвраты при set‑переменных/тестах и сделать код более устойчивым к нечисловым/пустым переменным (чтобы поведение было детерминированным).
Если нужно — могу приложить:
полный dump journalctl -u NetworkManager (полный файл nm.log)
текущий /etc/NetworkManager/dispatcher.d/01-ifupdown (полный текст — уже в запросе)
результат проверки с предложенным патчем (до/после: строки warning исчезают)
Вопросы к инженерам/разработчикам
Можно ли внести предлагаемый ранний exit 0 в основной пакет network-manager в следующем релизе?
Нужны ли дополнительные логи или автоматические тесты для CI (на малой архитектуре/образе Wiren Board)?
Добрый день. Есть обратная связь от разработчиков.
В том случае если настройки как раз поменяются - то скрипт в таком случае не отработает. Что может вызвать неконсистентное поведение.
А для чего именно перезапускать сервис?
То есть что за кейс.
Вот что говорит ваш цифровой умник с моими таблетками для памяти, с чего все началось:
Ниже — краткий, логичный и проверяемый отчёт для разработчиков с хронологией, анализом причины и практическими рекомендациями. Можно скопировать/вставить в багрепорт.
Краткая сводка
Симптом: python3 /usr/lib/wb-connect постоянно жрёт CPU (~27%), wb-connection-manager падает с ошибкой при попытке обратиться к D‑Bus NetworkManager (NameHasNoOwner). nmcli сообщает «NetworkManager is not running».
Причина (обнаружено по логам): NetworkManager не смог корректно обработать вызов dispatcher и завершился/остановился; как следствие DBus‑имя NM отсутствует — wb-connection-manager не может подключиться и уходит в ошибочные повторные попытки (высокая загрузка CPU).
Точка отказа: /etc/NetworkManager/dispatcher.d/01-ifupdown — скрипт завершился с кодом 1 при action=reapply/device-reapply и/или блокировал dispatcher, что привело к таймауту активации org.freedesktop.nm_dispatcher.
Хронология (из вашего журнального вывода, ключевые строки)
09:58:07 — WARNING: dispatcher: (11) /etc/NetworkManager/dispatcher.d/01-ifupdown failed (failed): Script ‘/etc/NetworkManager/dispatcher.d/01-ifupdown’ exited with status 1.
10:02:17 — dispatcher: failed (after 24.667 sec): Failed to activate service ‘org.freedesktop.nm_dispatcher’: timed out (service_start_timeout=25000ms)
10:02:19 — NetworkManager: exiting (success) (NM завершил работу; DBus‑имя пропало)
Анализ причинно‑следственной связи
Action=device-reapply/reapply запускает NM dispatcher, который синхронно вызывает /etc/NetworkManager/dispatcher.d/01-ifupdown.
Скрипт 01-ifupdown возвращает код 1 и/или выполняет длительные/блокирующие операции → dispatcher ждёт завершения (по умолчанию ~25 s) и фиксирует ошибку/таймаут при попытке запустить nm_dispatcher.
В результате NM переходит в неконсистентное состояние / теряет способность обслуживать D‑Bus‑запросы → systemd фиксирует ошибку GetNameOwner / далее NM закрывается.
wb-connection-manager (и/или wb-connect) при отсутствии DBus‑сервиса NM получает NameHasNoOwner и повторно/в цикле пытается подключиться — повышенная нагрузка CPU или падение процесса.
Влияние
Непредсказуемые отключения сети (интерфейсы становятся unmanaged), сервисы, зависящие от NM (wb-connection-manager, VPN, cloud agents) — недоступны.
wb-connect/wb-connection-manager генерирует ошибки/рестарты, что проявляется высоким CPU.
Рекомендации по исправлению (быстрые, конкретные)
Сделать dispatcher скрипт идемпотентным и ненадёжно ненадолго блокирующим: возвратить 0 как можно быстрее и выносить тяжёлую логику в фон. Пример:
Обрабатывать специально action=reapply/device-reapply: в фоновой задаче проверять текущее состояние (nmcli connection show --active, ip addr) и применять изменения только после короткой стабилизации (sleep 1–3s + проверка).