PC Linux qui démarre lentement ? Cet outil pratique montre pourquoi en quelques secondes - voici comment
Si votre machine Linux met un temps fou à démarrer, vous disposez d'un outil intégré pour vous aider à découvrir où se situe le problème.
Principaux points à retenir 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 prenant en charge systemd aura ceux-ci.
Linux dispose d'une tonne d'outils pratiques qui peuvent vous aider à découvrir ce qui va bien, ce qui ne va pas, et tout ce qui se trouve 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 dispose d'un outil intégré pour vous aider à faire exactement cela.
Si votre distribution Linux utilise le système d'init 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 fait cet outil, c'est analyser et déboguer le gestionnaire d'initialisation sous Linux.
Si vous exécutez simplement la commande systemd-analyze, vous verrez des résultats qui ressemblent à ceci :
Démarrage terminé en 6,669s (noyau) + 30,368s (espace utilisateur)=37,037s
cible graphique atteinte après 27,479s dans l'espace utilisateur
Comme vous pouvez le voir ci-dessus, le temps de démarrage total pour l'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.
Also :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 quelques options importantes que nous pouvons utiliser pour nous aider à comprendre ce qui se passe.
blâmer
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 blame est utilisée de cette manière :
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. Qu'est-ce que cette unité ? L'unité apt-daily.service est responsable de la vérification quotidienne automatique 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ûre pour accélérer le temps de 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 démarrer 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 prend en charge les fichiers SVG.
La commande pour cela ressemble à :
systemd-analyze plot > boot.svg
Vous trouverez alors le fichier .svg dans le répertoire de travail actuel. Je vous suggère d'ouvrir le fichier dans un navigateur web car la plupart des navigateurs web prennent en charge ce format de fichier, et l'image peut être assez grande.
Le fichier image peut être énorme.
Comme vous pouvez le voir sur mon échantillon, 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 entraînent un démarrage plus lent de votre système que prévu.