Résoudre les lenteurs au démarrage de Ubuntu-Mint

J’appelle problème bloquant, un problème m’empêchant d’utiliser un outil. Cela ne signifie pas obligatoirement “l’outil ne fonctionne pas” mais plus globalement “l’outil n’est pas utilisable pour moi en l’état“. C’est le cas ici, je teste Mint XFCE et j’ai un démarrage en 46 secondes. Le démarrage fonctionne mais le temps de démarrage est bloquant pour moi, hors de question de rester sur une distrib qui met autant de temps à démarrer. Je suis en dual-boot, Xubuntu démarre en 7s.

Identifier

Il est nécessaire de connaître deux commandes pour identifier les lenteurs au démarrage des systèmes d’exploitation utilisant systemd : systemd-analyze et systemd-analyze blame. Vous en croiserez parfois une troisième permettant de présenter les résultats de manière graphique : systemd-analyze plot (à utiliser ainsi systemd-analyze plot > boot.svg). Un man systemd-analyze vous renseignera sur la fonction de chacune.

Voici le résultat de systemd-analyze sur ma Mint XFCE. Le noyau Linux (kernel) met donc 35s au démarrage et l’espace utilisateur (userspace) 11s. C’est ce résultat que je désigne par “démarrage” dans cet article et pour être précis tiré du man : “the time spent in the kernel before userspace has been reached, the time spent in the initial RAM disk (initrd) before normal system userspace has been reached, and the time normal system userspace took to initialize”. On vient d’identifier deux problèmes, lenteur au niveau kernel et lenteur au niveau userspace.

Un systemd-analyze blame affiche le temps d’initialisation de chaque service et donne le résultat suivant (tronqué aux 5 premiers résultats). On identifie de suite la raison de la lenteur au démarrage de l’userspace : ntp.service. Ce service met 10s à s’initialiser à lui tout seul.

Je vous invite à tester en live ces commandes sur votre pc. L’immense majorité des services systemd démarrent en moins d’une seconde si vous avez un SSD. Évidemment certains services sont lourds/longs à démarrer : virtualisation, bases de données… Je simplifie mais tout service qui démarre en plus de 2-3 secondes mérite votre attention : Est-il nécessaire ? À quoi sert-il ? Pourquoi ce délai ?

Diagnostiquer

On commence à mettre les mains dedans : Qu’est-ce qui provoque ce délai et est-ce qu’une action change ce délai ? Commençons par le service ntp.

La bonne manière de procéder : 1/ Favoriser des tests aux résultats visibles et compréhensibles, ça oriente et confirme nos soupçons. On doit être sûr que c’est notre action qui a changé quelque chose, pouvoir constater un changement, comprendre ce qu’on a fait et ce qui s’est passé 2/ Effectuer des tests qui impactent le moins possible le système d’exploitation afin de pouvoir revenir en arrière (rollback) et reproduire la situation d’origine 3/ Pour rechercher et isoler la cause d’un problème, on va du grossier au précis. Plutôt que faire 100 tests sur des choses précises (plus long et difficile), il vaut mieux faire un test général pour savoir dans quelle direction poursuivre (disque, kernel, réseau, etc.) 4/ Créer des tests de sorte que problème/résultat soient reproductibles ainsi on teste et valide facilement/rapidement une action

Ici nous allons donc simplement désactiver le service ntp sudo systemctl disable ntp.service (pour rollback : sudo systemctl enable ntp.service), redémarrer sudo reboot puis afficher de nouveau le résultat systemd-analyze blame. Il est évident mais ça confirme qu’il n’y a pas d’effets indésirables dans l’immédiat : L’userspace démarre en moins de 2 secondes. On gagne près de 10s à chaque démarrage.

Repassons sur notre lenteur kernel. Lorsqu’on arrive sur Grub, on choisit Advanced options for Linux Mint 19 Xfce puis Linux Mint 19 XFCE (recovery mode) et on regarde ce qui se passe. Dans mon cas c’est simple, ça reste longtemps sur un message : Scanning for btrfs file systems. On va orienter nos recherches de ce côté-là.

Réparer

Le service ntp permet de fournir l’heure exacte au système d’exploitation, on ne peut pas se contenter de le laisser désactivé mais on peut probablement lui trouver un remplaçant. Je vous recommande chaudement chrony, vous pouvez aussi passer à systemd-timesyncd. Chrony est méconnu pourtant c’est la nouvelle référence, il est déjà utilisé de base sur les systèmes Fedora, CentOS, Red Hat. Sa configuration par défaut est sécurisée, correcte, il n’écoute qu’en local et n’agit qu’en client NTP. Il faut donc juste l’installer : sudo apt install chrony. On redémarre sudo reboot puis on affiche de nouveau le résultat systemd-analyze blame : La lenteur constatée niveau userspace a disparu, on a définitivement gagné 10s à chaque démarrage, le service chrony s’initialise en 54ms. On aurait pu creuser le problème du service NTP, ça aurait pris sûrement beaucoup plus de temps. Nous avons là une solution simple, rapide, satisfaisante.

En effectuant quelques recherches sur la lenteur niveau kernel, on apprend qu’il y a des problèmes avec le noyau 4.15.0-20. On vérifie notre noyau (uname -r), pas le même. Le plus évident lorsqu’on a un problème avec un noyau, c’est d’en tester un autre.

On se rend sur http://kernel.ubuntu.com/~kernel-ppa/mainline/ puis on cherche la dernière branche. Le plus simple étant de cliquer sur Last modified, actuellement le noyau le plus récent est le 4.18. Je n’aime pas prendre la dernière version, je lui préfère une version antérieure (par exemple la 4.17.12) : 1/ Les bugs commencent à être connus et identifiés, on peut retrouver leurs traces 2/ Trop récent, peu fiable.

On télécharge, on installe, on redémarre, on vérifie le noyau et systemd-analyze.

Pas de bol, pas mieux ! On a encore un démarrage kernel de plus de 30 secondes. À noter que sur Grub, on peut toujours choisir de booter sur l’ancien noyau. On va faire des recherches sur Scanning for btrfs file systems, je précise que je n’utilise pas btrfs sur mon pc.

Le premier lien est la solution qui a marché pour moi.

Je pense qu’une bonne explication est ici. Je recommande également ces liens connexes : 1, 2, 3, 4. Pour résumer il y a des problèmes si vous chiffrez votre /home notamment autour de la swap. Dans la release notes de Mint 19 XFCE, Known issues : There is an issue with home directory encryption that causes swap to be misconfigured during installation. To correct this…”

Conclusion

Au début de l’aventure.

Après la résolution du problème dans l’userspace (ntp.service).

À la fin de l’aventure (après la résolution du problème niveau kernel).

Je démarre à présent en moins de 6s, 40s gagnées à chaque démarrage, un confort indéniable. Soulignons le fait qu’une version LTS (Long Term Support) n’est pas exempte de soucis/bugs, que le démarrage est aussi concerné par des problèmes/optimisations.

J’ai essayé de vous fournir une méthodologie et quelques bases pour vous débrouiller avec des lenteurs au démarrage, l’article Danse avec les reboots est un bon complément. Les commentaires sont ouverts, je réponds aux questions.

Tcho !

Déjà 14 avis pertinents dans Résoudre les lenteurs au démarrage de Ubuntu-Mint

  • Article clair, détaillé, documenté, expliqué, bien tourné (un vrai petit polar). Simplement excellent ! Si je n’avais pas abandonné Facebook il y 5 ans, j’aurais sans doute mis un “j’aime” ;-) c’était un plaisir de te lire !
  • Bruno
    Merci pour l’info, j’ai retiré mysql au démarrage puisque je m’en sers très rarement en ce moment et j’ai sauvé une dizaine de secondes :) Les lenteurs sont surtout du côté userspace pour moi, avec Mint 18.2 + Cinnamon. J’y regarderai à nouveau quand je serai passé à Mint 19.
  • Yax
    Une méthodo pour le diagnostic : agréable à lire, l’utilisation de distributions “user-friendly” ne dispense pas de conserver ses acquis GNU/Linux pour résoudre ce genre de problème.
  • Alain Brisset
    Bonjour,bonsoir…………………n’ayant aucune prétention je ne puis que vous dire que chaque jour qui passe je me sens ,chaque fois, plus démuni……………J’aimerais tant avoir à dispo. une distro que se contente de fonctionner sans avoir à effectuer diff.réglages………………..j’avoue n’être qu’un utilisateur tout simple………….pour ce qui est de mon véhicule il ne m’es pas (encore!) imposé de prendre ce “carburant” par rappor à un autre!!!!…..Je ne râle pas, je ne dis que c’est dommage! Belle et bonne fin de journée!
  • Laurent
    , bonsoir, j’ai du mal à voir l’image que tu as posté, le lien semble mort depuis chez moi. Tu peux la mettre à disposition d’une autre manière je te prie ?
  • Phreg
    Bonjour, très bon article, bravo. Après ajout d’un SSD mSata, il me restait une lenteur due à un service réseau. Ce post m’a décidé à fouiller un peu et me rendre compte qu’il était inutile pour ma config. Le boot est passé de 18 à 11 secondes tout compris. C’est surtout pour la perfo, pas mal pour un vieux Thinkpad E330 I5 ! Merci pour m’avoir donné l’envie de fouiller.

Laisser un commentaire

indique des champs obligatoire.