Acabei de instalar o Ubuntu 24.04 em uma unidade Intel Optane p4801x. Estou tentando ver o quão rápido ele inicializa a partir deste disco. De fato, ele inicializa muito rápido. Mas a NetworkManagerunidade geralmente não inicia. Ela está habilitada, mas morta, e não há nada no journalctl -b 0 -u NetworkManager.service. Ou seja, a unidade nunca foi executada durante a inicialização. Quando eu mesmo a inicio após a inicialização, ela inicializa bem:
systemctl start NetworkManager
Os logs mostram que networkd-dispatcherfoi desabilitado para quebrar o ciclo de ordenação:
$ journalctl -b 0 | grep network
Oct 20 14:21:15 evergreens kernel: drop_monitor: Initializing network drop monitor service
Oct 20 14:21:15 evergreens systemd[1]: multi-user.target: Found ordering cycle on networkd-dispatcher.service/start
Oct 20 14:21:15 evergreens systemd[1]: multi-user.target: Job networkd-dispatcher.service/start deleted to break ordering cycle starting with multi-user.target/start
Oct 20 14:21:15 evergreens systemd[1]: Reached target network.target - Network.
Oct 20 14:21:15 evergreens systemd[1]: Reached target network-online.target - Network is Online.
...
Suspeito que isso fez com NetworkManagerque nunca fosse executado também.
O Systemd não mostra nenhum problema em nenhum dos dois:
$ sudo systemd-analyze verify networkd-dispatcher.service
$ sudo systemd-analyze verify NetworkManager.service
$
Mas o log na verdade mostra muito mais ciclos de ordenação, e isso aparece em verify multi-user.target:
$ journalctl -b 0 | grep "break.*cycle"
...
$ sudo systemd-analyze verify multi-user.target
...
Por exemplo, a rede:
$ sudo systemd-analyze verify multi-user.target 2>&1 | grep -i netwo
multi-user.target: Found dependency on network.target/start
ubuntu-advantage.service: Found ordering cycle on network.target/start
ubuntu-advantage.service: Job network.target/start deleted to break ordering cycle starting with ubuntu-advantage.service/start
multi-user.target: Found ordering cycle on networkd-dispatcher.service/start
multi-user.target: Job networkd-dispatcher.service/start deleted to break ordering cycle starting with multi-user.target/start
multi-user.target: Found ordering cycle on NetworkManager.service/start
multi-user.target: Job NetworkManager.service/start deleted to break ordering cycle starting with multi-user.target/start
Mas, parece que sudo systemd-analyze verify multi-user.target imprime coisas diferentes em quase toda vez que eu o executo ? Isso é possível? Às vezes, ele imprime muito mais, às vezes, apenas 1 unidade.
Tentei traçar as dependências multi-user.targetseguindo a resposta no Unix Stackexchange :
$ sudo systemd-analyze verify multi-user.target 2>&1 |\
perl -lne 'print $1 if m{Found.*?on\s+([^/]+)}' |\
xargs --no-run-if-empty systemd-analyze dot | dot -Tsvg > cycle.svg
Não consegui ver um ciclo ali. Além disso, o gráfico é grande e difícil de ler. Tentei "dar zoom" em algumas unidades como, mas também não vejo um ciclo ali:
$ echo multi-user.target networkd-dispatcher.service basic.target |\
xargs --no-run-if-empty systemd-analyze dot |\
dot -Tsvg > cycle.svg
Como systemd-analyze verifyele imprime coisas diferentes quase toda vez que é executado, esses gráficos provavelmente não são confiáveis.
Olhando para unidades individuais, não encontro problema. As NetworkManagerdependências parecem boas:
$ cat /usr/lib/systemd/system/NetworkManager.service
[Unit]
Description=Network Manager
Documentation=man:NetworkManager(8)
Wants=network.target
After=network-pre.target dbus.service
Before=network.target
BindsTo=dbus.service
...
[Install]
WantedBy=multi-user.target
Also=NetworkManager-dispatcher.service
Eu tive um problema parecido ao inicializar de uma unidade NVMe comum da Corsair. E nunca tive quando a inicialização do NVMe da Corsair era anormalmente lenta por causa de uma unidade específica. (Montando um disco HDD /etc/fstab- ele não está fstabmais lá, então não deixa a inicialização lenta.)
Ie Eu acho que esse problema acontece somente quando a sequência de boot é rápida. Embora eu não entenda por que isso seria o caso. Por que um problema no gráfico de dependência apareceria somente em boot rápido?
Alguém poderia sugerir como rastrear os ciclos de pedidos?
O que está acontecendo com systemd-analyze verify multi-user.targeta impressão de coisas diferentes a cada vez? Esse é um comportamento conhecido real? Como ele atravessa o gráfico de dependência, é de alguma forma aleatório? Isso pode estar relacionado à causa que faz o systemd excluir unidades durante a inicialização, mas as mesmas unidades rodam bem depois?