Quelques astuces à propos de systemd

Cet article a été publié il y a 9 ans 1 mois 19 jours, il est donc possible qu’il ne soit plus à jour. Les informations proposées sont donc peut-être expirées.

Qu’on le veuille ou non, systemd est là pour durer : ArchLinux et ses dérivées l’utilisent depuis un bon moment, Red Hat l’a inclus dans la version 7, qu’ils vont supporter pendant dix ans, Debian va l’utiliser dans la prochaine Jessie (qui est déjà en « feature freeze »), Canonical a annoncé suivre le mouvement dans Ubuntu, bref, tout le monde va en manger à toutes les sauces.

Considérations techniques de bas niveau mises à part, sur mon vieux coucou il faut admettre une chose : ça fonctionne, et (très) bien. D’ailleurs, si c’était si pourri, le projet serait déjà enterré, Red Hat ou pas derrière. Et donc pour me préparer le terrain sur mes serveurs Debian quand je mettrais à jour, je commence déjà à jouer avec sur mon laptop. Voici donc quelques bricoles glanées qui, on le verra, n’ont pas nécessairement d’équivalent ailleurs.

Ceci n’est pas un article complet sur systemd (d’ailleurs, c’est tout en minuscules qu’il faut l’écrire). Le bousin est assez monstrueux pour peu qu’on utilise tous ses modules, donc non, aujourd’hui, c’est de l’utilisation simple, de celle qu’on peut faire quelque soit le contexte. En particulier, il ne sera pas question de se créer des services, de bricoler les règles udev, ou je ne sais quoi qui demande d’abandonner tout rasoir pendant plusieurs jours/semaines. Pour vous faire une idée globale, c’est cet article qu’il faut lire.

Non, là, je me suis concentré sur quelques outils disponibles pour analyser le temps de démarrage et un peu l’architecture de ce démarrage (dépendances entre services, ce genre de choses). J’essaie aussi d’apprivoiser les journaux, parce que ça, sous Debian, c’est la vie (ou la mort, suivant que votre cerveau arrive à suivre ou pas).

Avant de commencer

Les différents outils de systemd proposent un affichage « particulier » de leurs informations : en effet, généralement, quand ça dépasse la taille de l’écran, il utilisent less pour pouvoir « naviguer » dans le résultat. Personnellement ça me gonfle un peu (surtout quand je veux simplement exporter le résultat dans un fichier), et fort heureusement, il est possible de contourner ce souci. Deux méthodes, soit ajouter l’option –no-pager à la commande saisie, soit ajouter/modifier une variable d’environnement. Et ça, on sait le faire depuis qu’on a trifouillé du bash à outrance. Donc, cette variable est la suivante :

Bon, voilà, c’est fait, passons aux choses sérieuses.

Quelques infos textuelles sur le démarrage

La commande la plus basique pour analyser le temps de démarrage d’une machine équipée de systemd est la suivante (j’affiche les résultats de mon laptop en exemple) :

Pas mal, pas mal. Bon, ça, c’est quand tout va bien, lors d’une mise à jour noyau, rajoutez une minute pour que dkms me reconstruise le module Virtualbox hein.

Vous constatez des chiffres plus élevés, voire anormalement élevés ? Un petit ajout à systemd-analyze devrait déjà être plus parlant :

Avouez que ça permet déjà d’en savoir beaucoup plus, non ? Si vous aussi vous avez percuté qu’ajouter tous les temps donnait un résultat plus grand, il ne faut pas oublier que systemd parallélise beaucoup.

D’ailleurs on va pouvoir le voir tout de suite, au sens propre du terme.

En mode graphique, ça vous dit ?

En effet, systemd permet de générer différents graphiques dans différents formats afin de mieux se représenter le démarrage d’une machine. Pour reprendre les informations du blame juste au dessus, on peut générer un graphe SVG de la manière suivante :

Attention, sans redirection, il inscrit la totalité des informations SVG sur la sortie standard. À moins d’avoir un cerveau digne de celui de Raymond Babbitt (ce qui peut poser quelques problèmes au quotidien, avouons-le), on prendra donc le soin, comme ici, d’enregistrer le résultat dans un fichier. On peut ensuite « rendre » ce fichier SVG dans GIMP par exemple pour obtenir un graphe de la sorte :

On peut aussi ouvrir directement le SVG dans Firefox, ce que je conseille pour une consultation simple. C’est quand même bien plus parlant non ? On retrouve donc le nom complet du noyau ainsi que le temps « général » qu’on a récupéré au début. On a ensuite un graphe « temporel » permettant de bien voir que beaucoup d’unités sont chargées en parallèle (on en voit d’ailleurs plus qu’en ligne de commande). La seule constante : le noyau, qui met un peu plus de deux secondes à se charger. Pas mal pour une machine qui a plus de six ans, n’est-il pas ? C’est normal, je carbure au SSD. D’après la légende en bas, le rouge « vif » représente le temps de chargement du service concerné.

Si on cherche à comprendre pourquoi une unité met autant de temps à charger, on peut analyser ses dépendances. En effet, pour savoir quoi charger à quel moment, systemd analyse les fichiers d’unité à la recherche des options After et Before afin de savoir ce qu’il doit lancer en premier pour être sûr de ne rien gaufrer. Pour voir le réseau de dépendances d’une unité en particulier, et ce de manière graphique, on doit procéder un peu différemment. En effet pour ce genre de graphiques, plutôt que le SVG systemd génère un graphe compatible avec l’outil dot contenu dans la suite GraphViz. L’installation de la suite est des plus simples :

Une fois installé on génère le graphe de dépendance d’une unité de la manière suivante :

On a donc à nouveau un graphe SVG qu’on peut ouvrir dans le navigateur. On peut aussi dire à dot d’utiliser directement un autre format de sortie. Il suffit de changer l’option pour -Tpng ou -Tgif pour générer des images correspondantes (pensez à adapter l’extension du fichier en conséquence). Exemple avec dkms, au format GIF :

Ce qui est dommage, c’est d’afficher bêtement la légende sur la sortie standard plutôt que l’embarquer dans le fichier.

Sachez une chose : les masochistes peuvent tenter de générer le graphe complet de dépendances du système. Mais alors là, attendez vous à un choc. Déjà, on se surprend à attendre, parce que c’est long à générer. Et puis on comprend : le fichier SVG fait la bagatelle de 492.7ko, ce qui est énorme pour du texte brut. On relance la génération en PNG ce coup-ci, et paf, un fichier image de 10.4Mo ! Généré en GIF, il ne fait plus « que » 2.9Mo, ouf ! Et à la vue du graphe, rien d’étonnant :

Vous avez l’impression de ne rien voir que de la bouillie ? Zoomez un peu, l’image mesure juste 17594 par 2747 pixels. Et c’est à la limite de l’imbuvable, mais ça donne une idée de la complexité d’un système d’exploitation moderne.

Le journal, un gros point noir

En effet, tout le monde adore la gestion actuelle des journaux/logs : tout dans du fichier texte, plus ou moins clair il est vrai suivant les applications, mais tout utilisable notamment par des outils qui vont scruter les fichiers afin d’en extraire la moelle. Le « patron » de Systemd, Lennart Poettering, a décidé de refaire tout ça de zéro et de développer une nouvelle infrastructure de journaux, stockés sous forme binaire, donc illisible par le commun des mortels barbus. Moralité pour y accéder, vous êtes obligés d’utiliser la commande journalctl, ce que pour le coup moi aussi je considère comme une sérieuse régression.

Donc les « astuces » présentées ici sont basiques, parce que j’éprouve beaucoup de réticence à m’y plonger pleinement, contrairement à d’autres « régions » de systemd. L’avantage, c’est que pour l’instant on peut définir autre chose à l’utilisation que journald (le démon de gestion des logs), et j’espère que les gars de Debian vont conserver rsyslog afin d’avoir nos bons vieux fichiers textes très efficaces (d’ailleurs, Fail2ban s’en sert pour faire son travail).

Enfin bref, malgré tout, journald apporte quelques fonctions qui pourraient avoir du sens. Notamment, même si ce n’est pas paramétré de la sorte chez moi, journald peut garder la trace des logs de plusieurs démarrages de la machine. Pour afficher les « boots » enregistrés :

La première colonne numérote les démarrages enregistrés : 0 pour le dernier en date, 1 pour le précédent, 2 pour l’antépénultième, etc. Pour afficher le détail d’un des démarrages, il suffit de noter son numéro dans la liste et d’invoquer journalctl avec les paramètres suivants :

On adaptera le nombre au boot désiré. Pourquoi disposer d’une telle fonctionnalité ? Elle pourrait s’avérer pratique pour comparer lorsque deux démarrages sont très différents (l’un rapide, l’autre lent) pour détecter un éventuel blocage qu’on aurait pas encore décelé. Mais j’avoue que c’est encore un peu flou pour moi.

Là où l’on peut voir un progrès, c’est que les messages, qui ont un « niveau d’alerte », peuvent être filtrés. En particulier, on cherchera à afficher les erreurs générées par les différents applications :

Il est vrai que Gwenview m’a posé quelques problèmes suite à sa mise à jour récente, mais ça pique un peu. Je pense savoir à quoi sont rattachées ces erreurs, sans pouvoir les corriger de moi-même toutefois. Je sais en tout cas ce qu’elles provoquent dans l’application, et ça ne me dérange pas outre mesure. Pareil pour GIMP, qui ne démarrait plus, mais là, c’était de ma faute (une tentative de personnalisation un peu viandée).

Il arrive parfois qu’on ai recours à tail -f pour afficher les nouvelles entrées en temps réel dans les fichiers de logs (je l’ai beaucoup pratiqué lors des dernières expérimentations sur PHP). Fort heureusement, on peut utiliser ce même switch avec journalctl, afin d’avoir un affichage temps réel :

Il affiche alors la date d’ancienneté du fichier actuel, les dix dernières lignes, et affichera les prochaines directement sur la sortie standard.

D’autres à venir

Voilà, c’est tout pour aujourd’hui. La prochaine fois, quand j’aurais un peu plus expérimenté, on pourra voir comment convertir un script de démarrage Debian fait maison pour Systemd. Nécessaire pour ceux qui comme moi font encore tourner des serveurs Call of Duty, par exemple.

Je vais peut-être directement m’installer une Jessie pour l’occasion, à moins de tester une migration Wheezy/Jessie, ce qui sera probablement le cas des machines virtuelles (y compris celle-ci). Mais je laisserais d’autres essuyer les plâtres, donc on a le temps 🙂