cClaude.rocks ☕ Le blog

Au démarrage d’un système d’exploitation comme Linux, il y a une myriade de services qui se lancent.

Et les questions auxquelles on souhaite avoir des réponses sont du genre :

• « Qu’est ce qui est long au démarrage ? »
• « Comment arrive à l’écran de connexion plus vite ? »
• Lorsque l’on rencontre un problème au démarrage : « Ou est-ce qui se passe ? »

La solution proposée par systemd

systemd-analyze

Permet d’avoir une vue générale sur le temps de démarrage de votre système d’exploitation.

Startup finished in 6.849s (firmware) + 3.836s (loader) + 4.312s (kernel) + 1min 30.342s (userspace) = 1min 45.340s
graphical.target reached after 6.247s in userspace

À noter que le résultat semble pouvoir varier considérablement entre un démarrage et un redémarrage :

# After power-on
Startup finished in 7.010s (firmware) + 3.961s (loader) + 4.120s (kernel) + 9.387s (userspace) = 24.478s
graphical.target reached after 9.363s in userspace

# After reboot
Startup finished in 7.592s (firmware) + 3.867s (loader) + 4.145s (kernel) + 1min 24.999s (userspace) = 1min 40.605s
graphical.target reached after 6.596s in userspace

Startup finished in 6.967s (firmware) + 3.889s (loader) + 4.128s (kernel) + 6.965s (userspace) = 21.950s
graphical.target reached after 6.957s in userspace

systemd-analyze --no-pager blame

Donne la liste et le temps que les services mettent pour se lancer, par exemple :

          3.848s NetworkManager-wait-online.service
          1.159s dev-nvme0n1p2.device
           649ms apt-daily-upgrade.service
           627ms snapd.service
           569ms systemd-journal-flush.service
           472ms systemd-logind.service
           437ms vboxdrv.service
           382ms snap-cmake-323.mount
           381ms dev-loop0.device
           380ms snap-core-8935.mount
           328ms snap-core18-1754.mount
           316ms keyboard-setup.service
           299ms dev-loop3.device
           292ms dev-loop1.device
           292ms dev-loop2.device
           244ms upower.service
           229ms systemd-hwdb-update.service
           220ms snap-core-9066.mount
           187ms systemd-udev-trigger.service
           167ms dev-loop4.device
           146ms snap-imaginary\x2dteleprompter-5.mount
           145ms lvm2-monitor.service
           140ms snap-core18-1705.mount
           139ms snap-cmake-340.mount
           134ms systemd-resolved.service
           131ms bash-desktop-configurator.service
           122ms systemd-udevd.service
           116ms NetworkManager.service
           115ms user@1001.service
           115ms systemd-fsck@dev-disk-by\x2duuid-52fffab2\x2ffd36\x2ff509\x2da7b1\x2d1fffeb2dff56.service
           112ms systemd-timesyncd.service
           111ms ModemManager.service
           108ms gpu-manager.service
           104ms accounts-daemon.service
            94ms udisks2.service
            75ms ubuntu-system-adjustments.service
            73ms swapfile.swap
            71ms apparmor.service
            68ms networkd-dispatcher.service
            61ms networking.service
            60ms systemd-journald.service
            60ms ufw.service
            59ms systemd-modules-load.service
            59ms kmod-static-nodes.service
            59ms grub-common.service
            59ms dev-hugepages.mount
            58ms run-rpc_pipefs.mount
            58ms sys-kernel-debug.mount
            56ms systemd-tmpfiles-setup.service
            54ms systemd-remount-fs.service
            48ms bluetooth.service
            45ms rpcbind.service
            42ms rsyslog.service
            41ms avahi-daemon.service
            41ms pppd-dns.service
            34ms nvidia-persistenced.service
            33ms dev-mqueue.mount
            33ms packagekit.service
            32ms wpa_supplicant.service
            31ms systemd-rfkill.service
            29ms alsa-restore.service
            29ms thermald.service
            28ms systemd-update-utmp.service
            25ms phpsessionclean.service
            24ms lm-sensors.service
            22ms systemd-fsck@dev-disk-by\x2duuid-0F0D\x2dff1B.service
            19ms colord.service
            19ms mnt-data.mount
            19ms ssh.service
            18ms lightdm.service
            17ms speech-dispatcher.service
            17ms hddtemp.service
            17ms apport.service
            16ms binfmt-support.service
            15ms plymouth-read-write.service
            15ms snapd.seeded.service
            15ms kerneloops.service
            14ms systemd-random-seed.service
            14ms dns-clean.service
            13ms systemd-tmpfiles-setup-dev.service
            13ms sys-kernel-config.mount
            13ms blk-availability.service
            13ms systemd-tmpfiles-clean.service
            13ms systemd-sysctl.service
            12ms finalrd.service
            11ms sys-fs-fuse-connections.mount
            11ms openvpn.service
            11ms systemd-user-sessions.service
            10ms lsyncd.service
            10ms polkit.service
             9ms nfs-config.service
             7ms snapd.socket
             7ms ureadahead-stop.service
             6ms console-setup.service
             5ms dev-loop5.device
             5ms proc-sys-fs-binfmt_misc.mount
             5ms motd-news.service
             4ms dev-loop6.device
             4ms boot-efi.mount
             4ms open-iscsi.service
             3ms plymouth-quit-wait.service
             3ms vboxweb-service.service
             3ms systemd-backlight@backlight:intel_backlight.service
             3ms systemd-update-utmp-runlevel.service
             3ms rtkit-daemon.service
             2ms vboxballoonctrl-service.service
             2ms vboxautostart-service.service
             1ms setvtrgb.service

systemd-analyze critical-chain

Les différents services doivent se lancer dans un certain ordre, mais certains peuvent être lancés parallèlement…

La durée du démarrage, ne correspond alors pas à la somme des temps de lancement de ces processus. Il s’agit de la somme des temps des processus « qui sont attendus pour continuer ».

La commande systemd-analyze critical-chain [UNIT …] affiche l’arbre de la chaîne critique
pour l’unité donnée. (pour chacune des « UNIT » spécifiées ou pour la chaîne par défaut).

Cela donne pour chaque étape, après que le caractère '@' le moment de l’exécution de la tâche et le temps de démarrage après le signe '+'.

Notez que cet affichage peut être trompeur. En effet, l’initialisation d’un service peut dépendre d’un déclencheur d’activation (« trigger ») provenant de l’exécution en parallèle d’une autre unité de traitement.

graphical.target @6.247s
└─lightdm.service @6.227s +18ms
  └─systemd-user-sessions.service @6.200s +11ms
    └─remote-fs.target @6.196s
      └─remote-fs-pre.target @6.195s
        └─open-iscsi.service @6.188s +4ms
          └─network-online.target @6.185s
            └─NetworkManager-wait-online.service @2.335s +3.848s
              └─NetworkManager.service @2.198s +116ms
                └─dbus.service @2.173s
                  └─basic.target @2.170s
                    └─sockets.target @2.169s
                      └─snapd.socket @2.160s +7ms
                        └─sysinit.target @2.142s
                          └─systemd-timesyncd.service @2.027s +112ms
                            └─systemd-tmpfiles-setup.service @1.966s +56ms
                              └─local-fs.target @1.958s
                                └─mnt-data.mount @1.937s +19ms
                                  └─systemd-fsck@dev-disk-by\x2duuid-dbb7ffb2\x2dffa6\x2dffa9\x2dafa1\x2d1eafebadff56.service @1.764s +115ms
                                    └─dev-disk-by\x2duuid-dbb7ffb2\x2dffa6\x2dffa9\x2dafa1\x2d1eafebadff56.device @1.763s

Quelques pistes d’optimisations

Ces pistes sont à prendre comme des exemples, ce sont des problèmes identifiés sur mes machines, vous n’avez probablement pas les mêmes optimisations à faire…

Ici, il s’agit plus d’illustrer une méthode que d’expliquer les cas exposés.

La table des partitions /etc/fstab

Un temps un peu long sur le montage des disques m’a fait regarder ma table des partitions.

cat /etc/fstab

Ce fichier contenait une ligne qui était inattendu :

/dev/disk/by-id/mmc-SC32G_0x3ce424fc-part1 /mnt/mmc-SC32G_0x3ce424fc-part1 auto nosuid,nodev,nofail,x-gvfs-show 0 0

Hors l’entrée /dev/disk/by-id/mmc-SC32G_0x3ce424fc-part1 n’existe pas sur ce système.

Cela se vérifie avec un simple :

ls -la /dev/disk/by-id/mmc-SC32G_0x3ce424fc-part1

J’ai donc mis cette ligne en commentaire en ajoutant le signe # en début de celle-ci.

Cela ressemble à un démontage de clé USB qui s’est mal passé (mais je n’ai pas vraiment creusé la question, puisqu’il s’agit d’une machine de développement et par conséquent le système d’exploitation est souvent mal mené)

Le service zeitgeist

Dans mon cas, c’est le traitement lié à l’utilisateur qui était lent. Du coup la commande suivante semblait adaptée :

systemd-analyze --user blame

Et j’ai eu le résultat suivant :

           465ms zeitgeist-fts.service
           230ms gvfs-goa-volume-monitor.service
           167ms zeitgeist.service
            26ms gvfs-gphoto2-volume-monitor.service
            24ms gvfs-mtp-volume-monitor.service
            22ms gvfs-udisks2-volume-monitor.service
             8ms gvfs-afc-volume-monitor.service
             8ms at-spi-dbus-bus.service
             7ms gvfs-daemon.service
             6ms obex.service
             6ms dbus.socket
             3ms gvfs-metadata.service

A priori, rien d’affolant, mais bon constatant que c’était le service zeitgeist-fts.service qui était le plus long à traité j’ai fait quelques recherches sur lui.

Au passage j’ai découvert le fichier : ~/.local/share/zeitgeist/activity.sqlite qui était d’une taille sympathique (80 584 704 octets – quand même) et qu’il est possible d’explorer à l’aide de :

sqlitebrowser ~/.local/share/zeitgeist/activity.sqlite

Par curiosité, je vous invite à faire un « browse table » sur la vue (« Views »)  : event_view…

Bref, ayant lu que le dossier pouvait être supprimé sans problème, eh bien :

rm -fr ~/.local/share/zeitgeist

Et on arrête la machine, pour la démarrer à nouveau (histoire d’avoir toujours la même référence)

Et là :

# after power-on and after removing ~/.local/share/zeitgeist directory
Startup finished in 6.967s (firmware) + 3.889s (loader) + 4.128s (kernel) + 6.965s (userspace) = 21.950s
graphical.target reached after 6.957s in userspace

À comparer avec le démarrage précédent :

# after power-on
Startup finished in 7.592s (firmware) + 3.867s (loader) + 4.145s (kernel) + 1min 24.999s (userspace) = 1min 40.605s
graphical.target reached after 6.596s in userspace

Rechercher les services qui ont planté au démarrage

Pour voir la liste des services qui n’ont pas correctement démarré, vous pouvez utiliser :

systemctl --failed

Et éventuellement :

systemctl --failed --no-pager --all

Ce qui sur une machine a donné :

  UNIT                         LOAD   ACTIVE SUB    DESCRIPTION
● fancontrol.service           loaded failed failed fan speed regulator
● systemd-hybrid-sleep.service loaded failed failed Hybrid Suspend+Hibernate

LOAD   = Reflects whether the unit definition was properly loaded.
ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
SUB    = The low-level unit activation state, values depend on unit type.

2 loaded units listed.
To show all installed unit files use 'systemctl list-unit-files'.

Compte tenu de la nature des services (rien de vital ici), on peut commencer par un :

sudo systemctl disable fancontrol.service

et un :

sudo systemctl disable systemd-hybrid-sleep.service

Références

• Manuel de systemd-analyze sur freedesktop.org,
• What zeitgeist is sur askubuntu.com,
• Page wikipédia de Zeitgeist

ᦿ