RSS
Suite du billet sur 👢 Linux : optimisation du démarrage et « logrotate » avec un autre cas, pour montrer que cela n’est pas toujours aussi simple…
ඏ
Première analyse
Commande : systemd-analyze --no-pager blame
systemd-analyze --no-pager blame
22.266s blueman-mechanism.service
15.815s networkd-dispatcher.service
14.666s gpu-manager.service
13.528s udisks2.service
…
Commande : systemd-analyze critical-chain
systemd-analyze critical-chain
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.
graphical.target @45.886s
└─multi-user.target @45.886s
└─blueman-mechanism.service @23.618s +22.266s
└─basic.target @23.581s
└─sockets.target @23.579s
└─uuidd.socket @23.576s
└─sysinit.target @23.408s
└─apparmor.service @21.266s +2.138s
└─local-fs.target @21.262s
└─boot-efi.mount @21.137s +122ms
└─systemd-fsck@dev-disk-by\x2duuid-C591\x2d3A52.service @20.541s +570ms
└─dev-disk-by\x2duuid-C591\x2d3A52.device @20.537s
Commande : systemd-analyze
systemd-analyze
Startup finished in 8.007s (kernel) + 45.902s (userspace) = 53.910s
graphical.target reached after 45.886s in userspace
On peut déduire de ces premiers résultats que le service blueman-mechanism.service semble être en cause.
ඏ
Désactivation du service « blueman-mechanism.service »
Le Bluetooth n’étant pas utilisé sur cette machine, on peut, dans un premier temps au moins, désactiver ce service.
sudo systemctl stop blueman-mechanism.service
sudo systemctl disable blueman-mechanism.service
Un redémarrage s’impose…
sudo reboot
ඏ
Analyse après le redémarrage
Commande : systemd-analyze critical-chain
systemd-analyze critical-chain
The time when unit became active or started is printed after the "@" character.
The time the unit took to start is printed after the "+" character.
graphical.target @43.799s
└─lightdm.service @43.297s +500ms
└─systemd-user-sessions.service @43.179s +115ms
└─remote-fs.target @43.108s
└─remote-fs-pre.target @43.108s
Commande : systemd-analyze
systemd-analyze
On obtient :
Startup finished in 7.963s (kernel) + 43.810s (userspace) = 51.773s
graphical.target reached after 43.799s in userspace
On avait :
Startup finished in 8.007s (kernel) + 45.902s (userspace) = 53.910s
graphical.target reached after 45.886s in userspace
Résultat on a gagné « 2 secondes », c’est sans doute pas là qu’il fallait chercher la lenteur…
ඏ
Réactivation du service "blueman-mechanism.service"
sudo systemctl enable blueman-mechanism.service
Il sera réactivé au prochain redémarrage…
ඏ
Pour aller plus loin dans l’analyse, il va falloir s’appuyer sur le journal système.
sudo journalctl -b
Sur la machine utilisée pour cet exemple, on trouve par exemple dans les logs une note nous conseillant de regarder :
man kernel_lockdown.7
Mais c’est un autre sujet…
ඏ
Liens
ᦿ
-
Vos commentaires
Pas encore de commentaire - ajouter le votre.
-
Ajouter votre commentaire