web-dev-qa-db-fra.com

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 bloque. Je suis à peu près sûr que c'est la panique du noyau parce que majuscule commence à clignoter.

Il y a quelques questions logiques sur ce qu'il faut faire et sur des bogues spécifiques, mais je suis vraiment en quête d'une chose: que s'est-il passé juste avant que tout soit mort?!

J'ai vérifié /var/log/kern.log et tout ce que je vois à peu près tout au long de cette journée, c’est que je mette un DVD, puis quelques minutes plus tard, le système s’amorce. Pas d'erreur, pas d'avis de panique.

Existe-t-il un moyen de forcer la panique à se connecter? Je suis à peu près sûr de pouvoir reproduire cela (c'est arrivé 100% des fois où j'ai essayé récemment), alors même si je préfère cela, je viens juste de "redémarrer", je suis assez content pour redémarrer à quelques reprises si cela signifie que je peux trouver la cause de la panique.

kernellog
29
Oli

Tous les journaux de votre système dans Ubuntu sont gérés par rsyslog qui conserve sa configuration dans /etc/rsyslog.conf et /etc/rsyslog.d/.

Pour plus d'informations sur la façon de configurer rsyslog et les options possibles, visitez le site rsyslog.conf man page .

En ouvrant /etc/rsyslog.d/50-default.conf, vous 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 journaux /var/log/syslog que vous aurez probablement.

Vous pouvez voir que le nom du fichier commence également par un -, cela signifie que le fichier est mis en cache avant l'écriture, c'est génial mais peut vous laisser avec un journal incorrect. Ce que vous voulez, c'est que le journal soit écrit dès qu'il y a un problème. . Supprimez le tiret et redémarrez ou rechargez rsyslog, puis bloquez à nouveau votre ordinateur, cochez /var/log/syslog.

20
Bruno Pereira

S'il s'agit vraiment d'une panique du noyau, il ne sera pas écrit dans un journal via des méthodes normales. Étant donné que le noyau est tombé en panne à ce stade, écrire dans le système de fichiers est une opération risquée - on ne peut plus faire confiance au noyau, il est donc possible que l'écriture dans les journaux crache une merde aléatoire 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. C'est ce qu'on appelle un crash/noyau.

Le wiki d'Ubuntu a un CrashdumpRecipe qui peut être utile - bien qu'il semble un peu dépassé, je ne pense pas que beaucoup aurait dû changer.

24
Caesium

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, dans la mesure où la transmission des données ne dépend que de simples câbles et de l'API du noyau, moins susceptibles d'être affectés par la panique que le sous-système TCP/IP, par exemple.

Inconvénients:

  • la plupart des ordinateurs portables modernes ne disposent plus du 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 la 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 toutefois être contourné avec un périphérique qui interface entre série et TCP/IP. Mais il existe des dispositifs qui convertissent entre les deux.

Le port série ressemble à ceci:

et sur le RPI est disponible via le GPIO.

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

screen /dev/ttyS0 115200

Cela vous donne en fait un shell.

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

Lorsque la panique se produit, la copie de panique est transmise à la deuxième machine et vous pouvez tout voir en faisant défiler l'écran vers le haut.

Autres méthodes

Il existe également d'autres méthodes permettant de surmonter les limitations matérielles mentionnées ci-dessus, au prix d'une complexité et d'une fiabilité accrues. Méthodes notables:

  • netdump: diffuse la panique sur TCP/IP. S'appuie sur le sous-système TCP/IP non corrompu.
  • kdump: semble être le mécanisme sous-jacent de linux-crashdump mentionné à l'adresse suivante: https://askubuntu.com/a/104793/52975 Amorce un deuxième noyau Linux pour examiner le noyau en panne. Qu'est ce qui pourrait aller mal?! :-)

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

Pas de débogage

En fin de compte, pour obtenir une sortie panique, certaines fonctionnalités du noyau doivent fonctionner, 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, regardez:

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

3
Ciro Santilli 新疆改造中心996ICU六四事件