Où sont les journaux de panique du noyau?

J'ai un problème avec Handbrake / ffmpeg. Après environ 5 minutes de transcodage, l'ordinateur se verrouille. Je suis assez sûr que c'est une panique du noyau parce que le verrouillage des majuscules commence à clignoter.

Il y a quelques questions logiques sur ce qu'il faut faire et d'autres sur des bugs spécifiques mais je suis vraiment après une chose: que s'est-il passé juste avant que tout ne meure?!

J'ai vérifié /var/log/kern.loget tout ce que je vois à ce moment-là, c'est que je colle un DVD, puis quelques minutes plus tard, le système démarre. Pas d'erreurs, pas de panique.

Existe-t-il un moyen de forcer l'enregistrement des paniques? Je suis assez sûr que je peux reproduire cela (c'est arrivé 100% des fois que j'ai essayé récemment), alors même si je préfère que cela "fonctionne", je suis assez heureux de redémarrer plusieurs fois si cela signifie que je peux trouver la cause de la panique.

Tous vos journaux système dans Ubuntu sont gérés par rsyslogqui conserve sa configuration dans /etc/rsyslog.confet /etc/rsyslog.d/.

Pour plus d'informations sur la configuration rsysloget les options possibles, visitez le rsyslog.conf man page.

En ouvrant, /etc/rsyslog.d/50-default.confvous pouvez voir que l'une des lignes contient

*.*;auth,authpriv.none -/var/log/syslog*

Cela signifie que le fichier que vous recherchez dans ce cas est l'un des énormes /var/log/syslogjournaux que vous aurez probablement.

Vous pouvez voir que le nom de fichier commence également par un -, cela signifie que le fichier est mis en cache avant l'écriture, c'est bien mais peut vous laisser un mauvais journal, ce que vous voulez, c'est que le journal soit écrit dès qu'il y a un problème. Retirez le tableau de bord et redémarrez ou rechargez rsyslog, puis faites à nouveau planter votre ordinateur, vérifiez /var/log/syslog.

Si c'est vraiment une panique du noyau, il ne sera pas écrit dans un journal via des méthodes normales. Depuis que le noyau est tombé en panne à ce stade, l'écriture dans le système de fichiers est une opération risquée - on ne peut plus faire confiance au noyau, donc les écritures dans les journaux peuvent en fait cracher des conneries aléatoires sur votre chargeur de démarrage!

Au lieu de cela, vous pouvez vider le contenu de la mémoire dans votre swap, puis le déboguer plus tard. Ceci est connu comme un crash du noyau / vidage du noyau.

Le wiki Ubuntu a une recette Crashdump qui peut être utile - même si elle semble un peu dépassée, je ne pense pas que trop aurait dû changer.

Port série

Le port série est un simple mécanisme de communication de bas niveau entre ordinateurs.

Avantages:

• configuration simple une fois (si vous avez le matériel)
• fiable, car la transmission de données ne dépend que de simples fils et API du noyau, qui sont moins susceptibles d'être affectés par la panique que, par exemple, le sous-système TCP / IP.

Inconvénients:

• la plupart des ordinateurs portables modernes n'ont plus de port série (exposé?) pour économiser de l'espace. Mais les ordinateurs de bureau et les machines virtuelles le font toujours.
• vous avez également besoin d'un deuxième ordinateur avec port série pour recevoir les données, mais c'est le cas pour pratiquement toutes les cartes de développement intégrées telles que le Raspberry Pi.
• limité par la longueur du câble série de la couche physique, contrairement aux réseaux TCP / IP qui sont illimités. Cela peut cependant être contourné avec un périphérique qui fait l'interface entre série et TCP / IP. Mais il existe des appareils qui convertissent entre les deux.

Le port série ressemble à ceci:

et sur le RPI est disponible via le GPIO.

Ensuite, si vous disposez du matériel requis, connectez-vous du deuxième ordinateur à l'ordinateur principal avec:

screen /dev/ttyS0 115200

Cela vous donne en fait une coquille.

Puis sur la machine principale, lancez l'opération qui panique.

Lorsque la panique se produit, le vidage de panique est diffusé sur la deuxième machine, et vous pouvez tout voir en faisant défiler vers le haut sur le terminal.

Autres méthodes

Il existe également d'autres méthodes qui surmontent les limitations matérielles mentionnées ci-dessus, au prix d'être plus complexes et moins fiables. Méthodes notables:

• netdump: diffuse la panique sur TCP / IP. Dépend du sous-système TCP / IP qui n'est pas corrompu.
• kdump: semble être le mécanisme sous-jacent de linux-crashdump mentionné à: https://askubuntu.com/a/104793/52975 Démarre un deuxième noyau Linux pour examiner le noyau écrasé. Qu'est ce qui pourrait aller mal?! :-)

Voir également cette excellente réponse: https://unix.stackexchange.com/questions/60574/determining-cause-of-linux-kernel-panic

Débogage par étapes

En fin de compte, obtenir une sortie de panique nécessite que certaines fonctionnalités du noyau fonctionnent, et toute fonctionnalité du noyau pourrait être corrompue par la panique.

Mais qui a besoin de panique si vous pouvez utiliser GDB sur le noyau? Si vous êtes aussi hardcore, jetez un œil à:

• QEMU ou autres machines virtuelles: https://stackoverflow.com/a/42316607/895245
• JTAG

Chaque problème tombe une fois que vous avez une visibilité complète (et suffisamment de temps!).