cClaude.rocks ☕ Le blog

[Nouvelles technologies du libre, sciences et coups de gueule…]

Menu

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

ᦿ


ℹ 2006 - 2024 | 🏠 Accueil du domaine | 🏡 Accueil du blog