La version 255 du composant systemd, trouvé dans la grande majorité des distributions Linux, intègre un élément qui peut prêter à sourire : l’équivalent de l’écran bleu de Windows. L’occasion de revenir sur ce grand symbole du plantage et son intérêt.
L’écran bleu est souvent appelé BSOD, pour « bleu screen of death » (écran bleu de la mort). Pourquoi cette appellation ? Parce que depuis bien longtemps, sous Windows, son apparition signifie un plantage si important du système que la seule solution est de redémarrer le système.
Sa signification n’a pas changé, même aujourd’hui. Sa forme a évolué plusieurs fois, mais il est toujours bleu et a toujours la même signification : une erreur si grave que tout s’est bloqué. Le fait qu’il soit devenu bien plus rare qu’avant n’y fait rien.
Un outil d’information et de diagnostic
Ces dernières années, et dans l’immense majorité des cas, l’écran bleu est provoqué par un pilote de mauvaise qualité. Avec le temps et le passage des versions successives de Windows, les pilotes ont vu leur champ d’actions resserré sur l’espace utilisateur, ne laissant disponible l’espace noyau que dans quelques scénarios, dont le plus connu est le pilote graphique. La qualité générale s’est en outre beaucoup améliorée, grâce à une infrastructure plus stricte.
Avoir un écran bleu aujourd’hui est rare et toujours synonyme d’un sérieux problème. Il peut survenir à cause d’un pilote, d’un matériel défectueux, d’une tentative ratée d’overclocking ou encore du dépassement d’un certain seuil de température par le processeur.
Cela étant, le BSOD n’a pas que vocation à annoncer une mauvaise nouvelle : il fournit également des informations. La première est bien sûr d’indiquer qu’un gros problème s’est produit et que la session est devenue inutilisable. La deuxième qu’un vidage de la mémoire est en cours (indiqué par un pourcentage). Ce « dump » pourra se retrouver ensuite dans le journal des évènements. C’est une source d’informations précieuse dans les dépannages, car le fichier DMP contient les conditions ayant mené au crash.
Deux autres informations sont présentes : un code QR (apparu avec Windows 10) et un code d’arrêt. Le premier renvoie vers une page du site de Microsoft sur les écrans bleus, le second donne le type d’erreur ayant provoqué le plantage.
C'est quoi systemd ?
Avant de plonger dans la version 255 de systemd, présentons brièvement ce composant – ou plutôt cette série de composants – que l’on trouve dans la plupart des distributions Linux. Toutes les Debian, Ubuntu, Fedora ou encore Arch Linux s’en servent depuis longtemps.
Dans les grandes lignes, systemd est responsable de nombreux processus impliqués dans le démarrage de l’ordinateur, dont l’initialisation, c’est-à-dire le tout premier programme à être exécuté. Il fournit de nombreux outils et capacités comme la gestion des dépendances entre services, le chargement en parallèle de ces derniers, la journalisation des évènements ou encore la gestion des connexions des périphériques.
Notez que systemd est tellement vaste dans ses possibilités qu’il est entouré depuis longtemps d’une polémique sur son utilisation. Linuxfr.org y avait consacré un vaste dossier en 2015.
Un BSOD dans systemd
Et voilà qu’arrive la version 255 de systemd, avec à son bord l’équivalent d’un BSOD. Et l’équipe de développement ne s’en cache pas, puisque le nouveau composant est sobrement appelé « systemd-bsod ».
L’objectif est simple : tout évènement atteignant un niveau de journal LOG_EMERG affichera ses informations en plein écran. « EMERG » signifie ici « emergency » (urgence). Le niveau en question signifie que le système est devenu inutilisable. Des informations techniques sont donc fournies, y compris un code QR renvoyant vers de plus amples informations.
Cet ajout a été pensé comme une nouveauté utile, même si elle peut prêter à sourire. Il s’agit cependant d’une fonction présentée comme expérimentale et qui pourrait donc évoluer dans les prochains mois. La version 255 étant finale, elle sera intégrée – elle ou une mouture ultérieure – dans la prochaine vague de distributions prévues dans la première moitié de 2024, notamment les futures Ubuntu et Fedora.
Si cet ajout est vite devenu le plus visible, il est loin d’être le seul. Certains sont d’ailleurs beaucoup plus utiles, comme une meilleure prise en charge des puces TPM et du chiffrement intégral des disques, la possibilité d’utiliser l’hibernation avec des partitions Btrfs, ou encore l’utilisation des PIDFD au lieu des PID pour la plupart des processus internes. On trouvera la liste complète sur le dépôt GitHub officiel, mais Phoronix a trié les points les plus importants.
Commentaires (43)
#1
Blague a part c'est vraiment le pire truc pour dénicher la panne.
Edit: C'est normal qu'il n'y ai plus de bouton pour les smileys et édition de text (gras/italic/etc...) ?
#1.1
C’est très compliqué car plus on ajoute des plugins wordpress plus on augmente le surface d’attaque du site 😞
#1.2
#2
Blague à part, c'est juste systemd, l'équivalent du BSOD c'est le kernel panic. Et là mieux vaut avoir un log sur port série actuellement, les kernels panics ne sont plus affichés sur les ordis de bureau (cause: pilotes graphiques, mode graphiques, ...). On a juste un figeage, parfois n'importe quoi à, l'écran mais plus aucune info sur l'écran.
#2.1
#2.2
#2.3
#2.4
#3
#4
#4.1
#5
#5.1
#5.2
Et le nombre de bombe permet de connaître la raison du plantage :
https://www.atariarchives.org/cfn/13/0222.php
Si j'avais su ça à l'époque, ça m'aurait bien aidé
#5.3
#6
#7
On trouve en effet un nombre impressionnant de recherche sur les significations des codes windows, sans jamais de réponse.
#7.1
#7.2
#7.3
Je n'ai jamais eu cette chance.
#7.5
Donc si, ça marche.
#7.6
#7.7
#7.8
#7.4
#8
#8.1
😁
#8.2
En fait et en général, je regarde les changelogs après, quand il y a des paquets mis à jour pour lesquels ça m’intéresse d’en connaître les changements.
#9
(pas garantie à 100 %)
#10
#11
Il me semblait qu’au début, il fallait réinstaller le système (quand ce n’était pas carrément lié à une panne matérielle).
Du coup le « de la mort » aujourd’hui n’est plus si pertinent (encore que la dernière fois que j’ai vu des BSoD, sous Windows 10, si un redémarrage fonctionnait, il revenait systématiquement après quelque temps, et même une réinstallation n’y avait rien fait, donc quelque part c’est pertinent) [et non la panne était pas matérielle, Linux tournait nickel sur la même machine].
Oh et l’indication d’erreur disait juste « arrêt imprévu », et les logs pareil. Jamais vu un système aussi muet. Comment voulez-vous déboguer dans ces conditions.
#11.1
Les écrans bleus des Windows NT, eux, provoquent de toute façon l’arrêt de l’OS et n’offrent pas d’autre choix que de réamorcer (d’ailleurs, c’est ce qu’ils font par défaut après le dump, si on n’a pas décoché la case demandant un redémarrage automatique). Même couleur de fond (je croyais qu’ils devaient être noirs sous Windows 11, et verts pour les préversions Insiders), mais pas les mêmes infos, ni le même fonctionnement.
#11.3
Sous Windows 3, il y avait très peu de crashes qui faisaient rebooter la machine ; le plus souvent, ça faisait juste planter Windows et tu revenais sous DOS. Ça revient au même qu'un reboot, puisque toutes tes applis étaient dégommées quand même.
#11.4
#11.5
Je pense sérieusement qu'il n'a jamais rien codé derrière [Retry] et [Ignore] :)
ça a été repris sous windows 95 par un écran bleu :
- Entrée (retry),
- Echap (ignore),
- Ctrl+Alt+Suppr (Abort)
un jour un dev a dû réaliser qu'il n'y avait aucun code derrière Entrée et Echap, il a virer ce faux choix et le BSOD moderne était né ne proposant que de redémarrer avec Ctrl+Alt+Suppr :)
#11.6
Non : ce dont tu parles, c’était juste le signe avant-coureur de l’écran bleu (qui apparaissait souvent après). Mais l’écran bleu n’est pas apparu avec Windows 95 : il date au plus tard de Windows 2 (sorti en 1987).
#11.2
J'ai quasi-jamais de BSOD mais les très rare fois où j'en ai, j'utilise WhoCrashed qui permet de lire le fichier dump.
#12
#12.1
#12.2
#12.3
#12.4
#13
Peut-être qu'un jour le projet Debian reviendra à la raison…