Quand une application plante sans générer d'erreur, y a-t-il un journal que je peux vérifier?
Il arrive parfois que certaines applications se bloquent sans donner aucune erreur de sortie (conky dans mon cas, une de mes configurations est probablement incorrecte).
Existe-t-il un journal d'erreur que je peux vérifier pour comprendre pourquoi il s'est écrasé?
Dépend de l'application. Différentes applications ont différents systèmes de journalisation. Il n'y a pas de journal central unique contenant toutes les sorties de tous les programmes exécutés sur votre système.
Cela étant dit, de nombreux programmes placent leurs fichiers journaux dans le répertoire /var/log. Le fichier /var/log/syslog (ou peut-être /var/log/messages), en particulier, contient la sortie du "consignateur système", qui est un service mis à disposition par le système que les programmes peuvent utiliser (s'ils le souhaitent) pour la journalisation. Mais tous les programmes ne l'utilisent pas. La plupart du temps, vous trouverez dans ce fichier des messages provenant de services système de bas niveau, mais pas des applications graphiques que vous utilisez probablement normalement.
Vous voudrez peut-être lire plus d'informations sur les emplacements des fichiers journaux standard .
les fichiers crash vont dans /var/log/crashes/ pour être utilisés avec apport afin de signaler les bugs. Vous pouvez extraire un core dump avec apport-unpack, le transférer via gdb et trouver la cause du blocage du programme.
Tout cela en supposant que vous soyez un programmeur. Si vous n'êtes pas ... eh bien, vous ne pouvez pas réparer le crash de toute façon!
Pour conky, il se peut également qu'il existe des entrées dans $HOME/.xsession-errors.
Certaines applications ont des indicateurs qui peuvent être utilisés pour activer le débogage, tels que -d, -D, --debug, etc. Consultez la page de manuel de l'application (man [my-app]) ou exécutez l'application avec l'indicateur -h une option.
De nombreuses applications d'interface graphique écrivent dans $ HOME/.xsession-errors, c'est donc un bon endroit pour vérifier la sortie.
maco a raison, ce qui est probablement le moyen le plus sûr d'obtenir de bonnes informations de débogage. Parfois, il ne capture pas le crash, cependant.
Si tout échoue, vous pouvez également forcer la suppression des informations en exécutant l'application dans gdb. Ce serait quelque chose comme:
$ gdb my-app
(gdb) run
... faites ce qu'il faut pour que ça tombe en panne ...
(gdb) bt full
et aller de là.
Si vous choisissez la route gdb, vous voudrez également installer les symboles, comme mentionné précédemment. Voir https://wiki.ubuntu.com/DebuggingProgramCrash pour des conseils pratiques.
vous pouvez aller à /var/log/messages or crashes puis vous pouvez exécuter la commande grep sur ceux-ci et rechercher l'application que vous cherchez peut parfois devenir assez gros. Il renverra des informations pertinentes pour votre application. :)
Si vous lancez votre application à partir d'un fichier de démarrage .desktop, ajoutez l'option Terminal=true à votre fichier .desktop. Cela ouvrira un terminal lorsque vous exécuterez le programme, la sortie sur le terminal sera similaire à ce que vous verriez si vous aviez exécuté le programme via la ligne de commande en premier lieu. Ainsi, lorsque l'interface graphique se bloque ou se bloque, vous pouvez voir quelle sortie de texte l'a précédée.