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.
Réponses:
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 lersyslog.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 rechargezrsyslog, puis faites à nouveau planter votre ordinateur, vérifiez/var/log/syslog.la source
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.
la source
linux-crashdump; ce package est toujours disponible dans toutes les versions.Port série
Le port série est un simple mécanisme de communication de bas niveau entre ordinateurs.
Avantages:
Inconvénients:
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:
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:
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 à:
Chaque problème tombe une fois que vous avez une visibilité complète (et suffisamment de temps!).
la source