init-скрипт NetworkManager запускается до udevd-final. До перехода на симлинк /var/run -> /run это не создаёт проблем. После перехода на симлинк NetworkManager не настраивает соединения, nm-applet сообщает, что интерфейсы не управляются. Определил опытным путём, что проблема в том, что NetworkManager запускается до udevd-final. Предлагаю добавить в LSB-header init-скрипта NetworkManager зависимость на udevd-final -# Required-Start: $local_fs messagebus -# Required-Stop: $local_fs messagebus +# Required-Start: $local_fs messagebus udevd-final +# Required-Stop: $local_fs messagebus udevd-final Проблема блокирует перевод регулярок/стартеркитов на симлинк: /var/run -> /run
Немножко не на тот пакет повесил. На NetworkManager-daemon надо.
Это может вызвать кучу проблем, приоритет udev-final аж 32. Т.е. NM будет запускаться очень поздно, многие сервисы, ожидающие поднятую сеть, будут работать неправильно. Надо посмотреть нельзя ли udev-final запускать раньше.
(В ответ на комментарий №2) > Это может вызвать кучу проблем, приоритет udev-final аж 32. Т.е. NM будет > запускаться очень поздно, многие сервисы, ожидающие поднятую сеть, будут > работать неправильно. Надо посмотреть нельзя ли udev-final запускать раньше. Согласен. Тогда перевешиваю на udev-rule-generator. И, возможно, стоит вообще на десктопах udev-rule-generator-net не использовать.
(In reply to comment #2) > приоритет udev-final аж 32. Интересно, почему 32, а не сразу после udev, скажем 03. udev что-то сделать не успевает до этого момента? Или просто так получилось?
(В ответ на комментарий №4) > (In reply to comment #2) > > > приоритет udev-final аж 32. > > Интересно, почему 32, а не сразу после udev, скажем 03. udev что-то сделать не > успевает до этого момента? Или просто так получилось?
(В ответ на комментарий №5) > (В ответ на комментарий №4) > > (In reply to comment #2) > > > > > приоритет udev-final аж 32. > > > > Интересно, почему 32, а не сразу после udev, скажем 03. udev что-то сделать не > > успевает до этого момента? Или просто так получилось? Мне тоже интересно. Но делать что будем?
Нашёл исходный коммит: http://git.altlinux.org/gears/u/udev.git?p=udev.git;a=commitdiff;h=5940de873bb9b5b01e30d1ac8e0a132e65143bf7 Some events cannot be handled completely at early boot stages. The udevd-final service retries failed events later, when other parts of the system have been initialized. This service also handles some shutdown actions, like saving ALSA mixer state, that cannot be performed from udev rules (previosly the hotplug service did this, but now it is obsolete). Вероятно, всё это уже не актуально.
(In reply to comment #7) > Вероятно, всё это уже не актуально. Тут что-то вообще не то: про сохранение настроек микшера. Единственное, что он делает при старте, это копирует /run/udev/tmp-rules--* в /etc/udev/rules.d/. Точнее дописывает к существующим файлам, если одноимённые встречаются. Если /run/udev/ гарантированно заполнен к концу service udev start, то 03 на стрте впоне нормально. Очерёдность stop вообще ни на что не влияет, там только $LOCKFILE удаляется. Но я не уверен, что раньше следующей недели смогу проверить. На самом деле есть ещё проблема: Bug #32166. Надо и её посмотреть.
У меня вообще сомнения, что udevd-final сейчас нужен. Возможно все должен делать сам udevd инит-скрипт. И тот тоже надо внимательно прочитать, я там видел что-то, что мне не понравилось.
(In reply to comment #9) > У меня вообще сомнения, что udevd-final сейчас нужен. В текущей реинкарнации udevd-final решал проблему https://bugzilla.altlinux.org/29282#c11 (In reply to comment #0) > Определил опытным путём, что проблема в том, что NetworkManager запускается до > udevd-final. Кстати, это должно влиять только при первом запуске. При последующих запусках persistent-net.rules уже должен существовать, и udevd-final уже ничего не делает в этой ситуации.
* Wed Sep 25 2019 Anton Midyukov <antohami at altlinux.org> 2:1.3-alt1 - run udevd-final before raising the network
