Oops du noyau au démarrage du VPN : des preuves à conserver

Démarrer le client VPN est un horodatage commode, non une cause, et cette distinction décide de la suite. Lorsqu’un Oops du noyau survient près de ce moment, le choix est entre recueillir un rapport de faute exploitable et provoquer cinq fois de plus le même plantage sur une machine de production. Conservez quatre choses avant de redémarrer : la compilation exacte du noyau, la première trace de la faute, l’état de taint et une description brève de tout le reste qui a changé dans la même minute. Le reste est interprétation, et l’interprétation peut attendre que les preuves soient en lieu sûr.

Capturez la première faute, pas la dernière ligne

Le premier Oops du journal est celui qui compte, car chaque faute ultérieure peut être un dommage collatéral d’un noyau déjà malade. Copiez l’en-tête avec la trace d’appels, car l’en-tête porte l’instruction fautive et l’état des registres qui identifient le chemin de code. Un rapport qui commence à la dernière ligne vaut très peu pour qui le lira une semaine plus tard.

Si la machine a déjà redémarré, le tampon noyau du démarrage précédent est souvent encore dans le journal, à condition que le stockage persistant ait été activé à ce moment-là. Lisez-le dans le fichier enregistré au lieu de recréer la charge de travail, car une seconde reproduction peut écraser ce dont vous avez besoin. Là où la machine ne peut pas conserver de journal entre les redémarrages, une console série ou netconsole est le seul moyen pour que la faute devienne visible.

Fixez la compilation avant de lire le moindre symbole

Les noms de fonctions et les décalages n’ont de sens que par rapport au binaire qui les a produits, aussi notez ensemble la chaîne de version du noyau et l’identifiant de compilation de la distribution. Un fichier de symboles d’une autre compilation pointe vers la mauvaise ligne avec une entière confiance, ce qui est pire que de n’avoir aucun symbole. Conservez la version du paquet noyau, pas seulement le numéro amont, car les distributions rétroportent beaucoup.

Les modules hors arbre méritent leur propre ligne dans le relevé, car un noyau marqué limite ce qu’un mainteneur est autorisé à conclure. Lisez la valeur de taint plutôt que de la déduire d’une liste de modules.

Un taint non nul n’est pas une accusation et ne rend pas le rapport sans valeur. Il indique au lecteur quels composants étaient chargés au moment de la faute, et certains indicateurs font qu’un rapport est dépriorisé par politique plutôt que par jugement. Notez la valeur, les noms des modules et si le même matériel et la même charge ont déjà tourné sur un noyau sans eux. C’est cette dernière comparaison qui sépare une nouvelle régression d’un défaut ancien.

Séparez un déclencheur d’un défaut

Démarrer le tunnel exerce normalement un chemin qui existait déjà : un pilote réseau, une discipline de file, une fonction d’offload ou un état d’alimentation. Le déclencheur explique quand la faute apparaît, non quel code est faux, et traiter le déclencheur comme la cause mène à une série de changements de configuration qui ne corrigent rien.

Une image antérieure qui fonctionne est une preuve, non une démonstration. Changez un composant par démarrage lors de la comparaison, et gardez les résultats quelque part qui survive à la machine.

Vérifiez ce que le mainteneur peut réellement utiliser

Lisez le rapport comme le ferait un inconnu avant de l’envoyer. Si la configuration, la séquence exacte et l’identité de compilation sont présentes, et que les identifiants ont disparu, le rapport est utilisable. S’il s’agit d’une capture d’une trace de pile, il reviendra avec une demande des mêmes informations. Le guide de recherche de bogues du noyau décrit à quoi ressemblent une trace utile et des symboles concordants.

uname -r
cat /proc/sys/kernel/tainted
journalctl -k -b -1 --no-pager | sed -n '/BUG:/,/Call Trace/p'
dmesg -T | grep -A 40 'RIP:'

Chaque commande ci-dessus ne fait que lire l’état, et les deux premières devraient tourner avant le prochain redémarrage si la machine peut encore y répondre. Là où le journal n’est pas persistant, ces deux-là sont les seules qui fonctionneront jamais de nouveau.

Masquez les clés, les mots de passe et le trafic non lié, mais conservez les noms de fonctions et les décalages dont quelqu’un a besoin pour lire la trace. Envoyez le matériel par la voie de signalement qui s’applique à la distribution ou au noyau, pas par un collage public accompagné d’un nom d’hôte. Attendez ensuite une question au lieu de récolter d’autres plantages, car une faute localisée face à une compilation correspondante est le seul résultat qui fasse avancer le rapport. Si rien ne revient, l’alternative est une reproduction contrôlée sur du matériel de rechange, jamais sur la machine dont d’autres personnes dépendent.