Vous trouvez que votre Linux met 3 plombes \u00e0 d\u00e9marrer et vous regardez l’\u00e9cran de boot d\u00e9filer en vous demandant ce qui peut bien prendre autant de temps ?<\/p>\n
H\u00e9 bien bonne nouvelle los amigos del manchos, si vous utilisez une distribution bas\u00e9e sur systemd<\/strong> (comme Debian, Ubuntu, Fedora, Arch, et compagnie), il existe un outil natif d\u00e9j\u00e0 install\u00e9 qui permet de diagnostiquer tout \u00e7a : Ce truc c’est un peu le m\u00e9decin l\u00e9giste de votre d\u00e9marrage syst\u00e8me. Il diss\u00e8que chaque \u00e9tape, identifie les unit\u00e9s qui tra\u00eenent la patte, et vous permet de comprendre o\u00f9 part votre pr\u00e9cieux temps. Pour ceux qui d\u00e9barquent, systemd est le syst\u00e8me d’initialisation adopt\u00e9 par la plupart des distributions modernes, et il permet justement de lancer plein de trucs en parall\u00e8le pour gagner du temps.<\/p>\n Pour commencer, la commande de base c’est tout simplement :<\/p>\n Elle vous sort un r\u00e9capitulatif du temps pass\u00e9 dans chaque phase, g\u00e9n\u00e9ralement le kernel, l’initrd (le RAM disk initial), et l’espace utilisateur. Selon votre configuration, vous pourriez aussi voir passer le firmware ou le bootloader. \u00c7a donne un truc du genre “Startup finished in 2.5s (kernel) + 19s (initrd) + 47s (userspace)<\/em>“. D\u00e9j\u00e0 l\u00e0, vous savez si le probl\u00e8me vient de votre noyau ou de vos services.<\/p>\n Mais le truc vraiment cool pour fouiller un peu plus dans le d\u00e9tail, c’est :<\/p>\n Cette commande vous balance la liste des unit\u00e9s systemd, tri\u00e9es par le temps qu’elles ont mis \u00e0 s’initialiser. C’est un peu comme un classement des cancres de la Ve R\u00e9publique. Vous voyez direct qui sont les boulets qui ralentissent tout le monde. Genre ce service r\u00e9seau qui attend 20 secondes une connexion qui n’arrivera jamais, ou ce truc de logs qui prend son temps pour se r\u00e9veiller.<\/p>\n Attention quand m\u00eame, y’a un petit pi\u00e8ge car un service qui met 10 secondes \u00e0 d\u00e9marrer ne signifie pas forc\u00e9ment que votre boot est rallong\u00e9 de 10 secondes. Pourquoi me diriez-vous ? H\u00e9 bien parce que systemd lance plein de trucs en parall\u00e8le. Un service peut donc prendre son temps tranquille pendant que d’autres bossent en m\u00eame temps sans bloquer personne.<\/p>\n Pour vraiment piger ce qui coince sur le chemin critique, lancez plut\u00f4t :<\/p>\n \u00c7a, c’est le top car \u00e7a vous montre la cha\u00eene critique, c’est-\u00e0-dire la s\u00e9quence exacte d’\u00e9v\u00e9nements qui d\u00e9termine vraiment votre temps de d\u00e9marrage final. Vous voyez exactement quelles unit\u00e9s sont sur le chemin et lesquelles attendent les autres. Le temps apr\u00e8s le “@” indique quand l’unit\u00e9 est devenue active, et le temps apr\u00e8s le “+” montre combien de temps elle a pris pour d\u00e9marrer. C’est bien plus fiable que blame<\/em> pour identifier les vrais goulots d’\u00e9tranglement.<\/p>\n Et si vous \u00eates du genre visuel, y’a m\u00eame :<\/p>\n Et avec \u00e7a, hop, \u00e7a g\u00e9n\u00e8rera un magnifique graphique SVG qui repr\u00e9sentera la chronologie de votre s\u00e9quence de boot. Vous pourrez ensuite l’ouvrir dans votre navigateur et voir en un coup d’oeil ce qui d\u00e9marre quand et combien de temps \u00e7a dure. C’est super pratique pour \u00e9pater la galerie ou juste visualiser l’ordre de lancement.<\/p>\n Maintenant, une fois que vous avez identifi\u00e9 les coupables, comment on fait pour acc\u00e9l\u00e9rer tout \u00e7a ?<\/p>\n D\u00e9j\u00e0, vous pouvez d\u00e9sactiver les services dont vous n’avez pas besoin avec :<\/p>\n Gardez en t\u00eate que disable<\/em> supprime seulement le lancement automatique au boot, mais n’emp\u00eache pas une activation indirecte via une d\u00e9pendance ou un socket. Si vous voulez vraiment qu’un service ne d\u00e9marre plus jamais, utilisez mask<\/strong><\/em>. Et surtout, ne d\u00e9sactivez pas n’importe quoi comme un bourrin, hein ! Je vous connais ! Non, non, avant de toucher \u00e0 un service, v\u00e9rifiez d’abord ce qui en d\u00e9pend :<\/p>\n Car si vous cassez un truc important, votre syst\u00e8me risque de ne plus d\u00e9marrer correctement. Donc si vous n’\u00eates pas s\u00fbr, gardez vos mimines dans vos poches. D’ailleurs, si vous bidouillez vos fichiers d’unit\u00e9 (comme pour
\nsystemd-analyze<\/a>\n<\/p>\nsystemd-analyze time\n<\/span><\/span><\/code><\/pre>\nsystemd-analyze blame\n<\/span><\/span><\/code><\/pre>\nsystemd-analyze critical-chain\n<\/span><\/span><\/code><\/pre>\nsystemd-analyze plot > boot.svg\n<\/span><\/span><\/code><\/pre>\nsudo systemctl disable nom-du-service\n<\/span><\/span><\/code><\/pre>\nsystemctl list-dependencies nom-du-service\n<\/span><\/span><\/code><\/pre>\n
\nautomatiser Shiori<\/a>
\npar exemple), sachez que vous pouvez aussi les v\u00e9rifier pour d\u00e9busquer les erreurs avec :<\/p>\n