NetworkManager-wait-online.service – различное поведение на двух машинах

[madesta]

Преамбула. Навеяно п.3 этой публикации.
На своём свежеустановленном LM22 обнаружил насторожившую меня запись: при загрузке системы
– 10.851s NetworkManager-wait-online.service
При этом вывод systemd-analyze:
Startup finished in 2.950s (kernel) + 18.340s (userspace) = 21.291s
graphical.target reached after 18.311s in userspace.
И это на диске SSD Samsung SSD 850 PRO 256GB (EXM04B6Q)
Предполагаю, что если выключу эту службу, то ситуация должна улучшиться. После sudo systemctl disable NetworkManager-wait-online.service получаю, что:
Startup finished in 2.945s (kernel) + 7.571s (userspace) = 10.517s
graphical.target reached after 7.537s in userspace.
Можно считать, что успех
Повторяю действия на второй машине с LM21.3 и тоже с диском SSD, но, думаю, похуже, чем на машине выше – Apacer AS350 1TB (W0424A0) через SATA.
Там ситуация другая – 29ms NetworkManager-wait-online.service
Ладно, ради чистоты эксперимента тоже отключаю эту службу. И, неожиданно, получаю ухудшение.
До отключения службы:
Startup finished in 6.648s (kernel) + 2.926s (userspace) = 9.575s
graphical.target reached after 2.856s in userspace
После отключения службы:
Startup finished in 6.766s (kernel) + 3.082s (userspace) = 9.849s
graphical.target reached after 2.936s in userspace
И как это следует понимать?

[Chocobo]

И это на диске SSD Samsung SSD 850 PRO 256GB

нутк wait-online сам по себе не очень связан с дисковой подсистемой, логичней сравнивать сетевухи)

[rogoznik]

9.575s ... 9.849s

Разница на уровне погрешности 300мс

[madesta]

логичней сравнивать сетевухи

"Проблемный" хост:

Network:
Device-1: Broadcom NetXtreme BCM57765 Gigabit Ethernet PCIe driver: tg3
v: kernel port: N/A bus-ID: 02:00.0
IF: enp2s0f0 state: up speed: 100 Mbps duplex: full mac: <filter>
Device-2: Broadcom BCM4331 802.11a/b/g/n vendor: Apple AirPort Extreme
driver: wl v: kernel bus-ID: 03:00.0
IF: wlp3s0 state: down mac: <filter>
Bluetooth:
Device-1: Apple Bluetooth Host Controller driver: btusb v: 0.8 type: USB
bus-ID: 3-1.1.3:6
Report: hciconfig ID: hci0 rfk-id: 2 state: up address: <filter> bt-v: 4.0
lmp-v: 6

Не "проблемный" хост:

Network:
Device-1: Realtek RTL8111/8168/8411 PCI Express Gigabit Ethernet
vendor: ASRock driver: r8169 v: kernel port: e000 bus-ID: 02:00.0
IF: enp2s0 state: up speed: 100 Mbps duplex: full mac: <filter>

Разница на уровне погрешности 300мс

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

Возможно, что изначальная разница в показаниях была обусловлена тем, что служба Bluetooth пытается чего-то там найти. Подключаемых по bluettoth устройств у меня не имеется и, возможно, целесообразнее было бы Bluetooth отключить, как сейчас через NM отключён WiFi. Ещё одним вариантом, который имеет более низкий "вес", является предположение о том, что слишком долго идёт процесс получения от роутера аренды адреса. Ещё после установки системы столкнулся с проблемой, которой в принципе не должно было возникнуть (ссылка на тему).
В настоящее время склонен полагать, что вопрос в конкретном оборудовании (железо). "Проблемный" хост – это Macmini, который мне просто подарили, на котором была снесена старая протухшая ось Mac и установлен LM. На эту мыль наводят данные о времени "задумчивости" NM при старте системы. На "проблемной" машине – 4.201s NetworkManager.service, на условно нормальной – 648ms NetworkManager.service С железом приходится мириться, так как "дарёному коню в зубы не смотрят".

P.S. Помню ещё на старой системе экспериментировал со сносом NM и использованием вместо него systemd. Ожидалось, что будет существенный выигрыш во времени старта, но на практике вышло не так уже и много, где-то порядка 3-4 секунд.

[rogoznik]

В сети не нашёл однозначного ответа стоит ли гасить эту службу или не стоит.

Вот тут интересные мысли есть по поводу этой службы

[Chocobo]

Если заглянуть в /lib/systemd/system/NetworkManager-wait-online.service
то мы видим следующее

[Service]
# `nm-online -s` waits until the point when NetworkManager logs
# "startup complete". That is when startup actions are settled and
# devices and profiles reached a conclusive activated or deactivated
# state. It depends on which profiles are configured to autoconnect and
# also depends on profile settings like ipv4.may-fail/ipv6.may-fail,
# which affect when a profile is considered fully activated.
# Check NetworkManager logs to find out why wait-online takes a certain
# time.

По цифрам вполне сходится (~7sec) у меня: