cClaude.rocks ☕ Le blog

L'informatique et les nouvelles technologies

Menu
Ce billet a été édité le : 2020-06-10

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ĂȘme 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 m’était inconnue :

/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

Recherches les services qui ont plantés au démarrage

Pour voir la liste des services qui n'ont pas correctement démarrer, 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

኿


â„č 2006 - 2021 | 🕾 Retour Ă  l'accueil du domaine | 🏡 Retour Ă  l'accueil du blog