PC Linux qui démarre lentement ? Cet outil pratique montre pourquoi en quelques secondes - voici comment
Si votre machine Linux met beaucoup de temps à démarrer, vous disposez d'un outil intégré pour vous aider à découvrir où se trouve le problème.
Points clés de Linux-Terminal.com
- Si le démarrage de votre machine Linux est lent, essayez cet outil.
- Systemd-analyze offre plusieurs options pour aider.
- Toute machine Linux compatible avec systemd les aura.
Linux a une tonne d'outils pratiques qui peuvent vous aider à découvrir ce qui est correct, ce qui est incorrect et tout ce qu'il y a entre les deux. Vous pouvez le personnaliser à votre guise ou le laisser tel quel.
À un moment donné, vous pourriez être curieux de savoir ce qui ralentit le temps de démarrage de votre machine Linux. Bien que cela puisse sembler être une tâche difficile, vous seriez surpris de voir à quel point c'est en réalité facile. En fait, Linux possède un outil intégré pour vous aider à faire exactement cela.
Si votre distribution Linux utilise le système d'initialisation systemd, vous avez déjà ce qu'il vous faut pour résoudre le problème des temps de démarrage lents, et je vais vous montrer comment utiliser l'outil.
systemd-analyze
L'outil en question fait partie du système d'initialisation systemd, et il s'appelle systemd-analyze. Ce que cet outil fait est d'analyser et de déboguer le gestionnaire d'initialisation sous Linux.
Si vous deviez simplement exécuter la commande systemd-analyze, vous verriez des résultats ressemblant à ceci :
Démarrage terminé en 6,669 s (noyau) + 30,368 s (espace utilisateur)=37,037 s
cible graphique atteinte après 27,479 s dans l'espace utilisateur
Comme vous pouvez le voir ci-dessus, le temps de démarrage total pour une de mes machines est de 37,037 secondes, avec 6,669 s pour le noyau et 30,368 secondes pour les applications en espace utilisateur. Ensuite, il y a le graphical.target atteint (l'écran de connexion) à 27,479 secondes.
Également : 8 choses que vous pouvez faire avec Linux que vous ne pouvez pas faire avec MacOS ou Windows
C'est une information assez bonne, mais elle ne nous aide pas vraiment beaucoup. La bonne nouvelle est qu'il y a certaines options importantes que nous pouvons utiliser pour nous aider à comprendre ce qui se passe.
blâme
La première option est blame, qui liste tous les fichiers d'unité systemd, en montrant le temps que chaque unité a pris pour s'initialiser lors du dernier démarrage, du plus long au plus court. L'option blame est utile pour identifier quels services causent des retards au démarrage.
L'option de reproche est utilisée de cette façon :
systemd-analyze blame
Les résultats ressembleront à ceci :
57,158s apt-daily.service
20,879s apt-daily-upgrade.service
17,609s snapd.service
10,647s docker.service
7,217s snapd.seeded.service
4,772s fstrim.service
4,160s dev-sda2.device
3,824s motd-news.service
3,756s cloud-init-local.service
3,369s cloud-config.service
3,173s snap.lxd.activate.service
2,932s containerd.service
2,877s cloud-final.service
2,677s systemd-udev-settle.service
2,498s cloud-init.service
2,125s networkd-dispatcher.service
2,051s man-db.service
Comme vous pouvez le voir, apt-daily.service est l'unité systemd qui prend le plus de temps. Quelle est cette unité ? L'unité apt-daily.service est responsable de la vérification automatique quotidienne des mises à jour logicielles sur les distributions Linux basées sur Debian.
Bien que vous puissiez arrêter apt-daily.service, je ne le recommanderais pas. Vous pouvez parcourir la liste générée par systemd-analyze blame et voir s'il y a des services que vous pouvez désactiver de manière fiable et sécuritaire pour accélérer le démarrage.
chaîne critique
L'option de chaîne critique affiche la chaîne d'unités qui a ralenti de manière critique le processus de démarrage. Cette option aide à identifier les goulots d'étranglement dans la chaîne de dépendances. Dans la sortie, le moment où une unité devient active est imprimé après le caractère @, et le temps que l'unité a mis pour démarrer est imprimé après le caractère +.
La sortie pour la chaîne critique ressemble à ceci :
graphical.target @27.479s
└─multi-user.target @27.478s
└─docker.service @16.830s +10.647s
└─containerd.service @13.891s +2.932s
└─dbus.service @13.869s
└─basic.target @13.796s
└─sockets.target @13.794s
└─snapd.socket @13.745s +44ms
└─sysinit.target @13.659s
└─cloud-init.service @11.149s +2.498s
└─systemd-networkd-wait-online.service @10.024s +1.118s
└─systemd-networkd. service @9.838s +180ms
└─network-pre.target @9.832s
└─cloud-init-local.service @6.073s +3.756s
└─systemd-remount-fs.service @1.434s +174ms
└─systemd-journald.socket @1.147s
└─system.slice @1.067s
└─-.slice @1.067s
Comme vous pouvez le voir, les deux services qui pourraient causer des goulots d'étranglement sur ce système (une machine Ubuntu Server) sont docker.service et containerd.service. Si je voulais accélérer le temps de démarrage, je pourrais désactiver ces services au démarrage et les lancer manuellement.
intrigue
Enfin, nous avons plot, qui génère un fichier .svg (Scalable Vector Graphic) représentant visuellement le processus de démarrage et les dépendances associées. Une fois le fichier généré, vous pouvez l’ouvrir dans un navigateur web ou un visualiseur d’images qui supporte les fichiers SVG.
La commande pour cela ressemble à :
systemd-analyze plot > boot.svg
Vous trouverez ensuite le fichier .svg dans le répertoire de travail actuel. Je suggérerais d'ouvrir le fichier dans un navigateur web parce que la plupart des navigateurs web prennent en charge ce format de fichier, et l'image peut être plutôt grande.
Le fichier image peut être énorme.
Comme vous pouvez le voir dans mon exemple, c'est vers 18 secondes que la majorité des applications et services commencent à s'initialiser.
L'outil systemd-analyze est pratique à avoir sous la main. Avec lui, vous pouvez commencer à résoudre les problèmes qui font que votre système démarre plus lentement que prévu.