エラーを出力せずにアプリケーションがクラッシュした場合、確認できるログはありますか？

出力エラーが発生せずに一部のアプリケーションがクラッシュすることがあります（私の場合はconkyで、おそらく私の構成の1つが正しくありません）。

クラッシュした理由を理解するために確認できるエラーログがどこかにありますか？

アプリケーションに依存します。アプリケーションごとにロギングシステムが異なります。システムで実行されるすべてのプログラムからのすべての出力を含む1つの中央ログはありません。

そうは言っても、多くのプログラムはログファイルをディレクトリに保存します/var/log。ファイル/var/log/syslog（または場合によっては/var/log/messages）には、特に、「システムロガー」からの出力が含まれます。システムロガーは、プログラムが（必要に応じて）ロギングに使用できるシステムによって利用可能になるサービスです。しかし、すべてのプログラムがそれを使用するわけではありません。ほとんどの場合、通常使用するグラフィカルアプリケーションではなく、そのファイルに低レベルのシステムサービスからのメッセージがあります。

標準ログファイルの場所について詳しくお読みください。

クラッシュファイルは、/var/log/crashes/バグを報告するためにapportで使用するために保存されます。を使用してコアダンプを抽出しapport-unpack、そのコアダンプをgdbに入力して、プログラムがクラッシュする原因を見つけます。

これはすべて、あなたがプログラマーであることを前提としています。そうでない場合は...まあ、とにかくクラッシュを修正することはできません！

conkyの場合、にエントリがあることもあります$HOME/.xsession-errors。

一部のアプリケーションには、-d、-D、-debugなど、デバッグを有効にするために使用できるフラグがあります。アプリケーションのmanページ（man [my-app]）、またはそのようなANを持っているかどうかを確認するには、-hフラグでアプリケーションを実行しますオプション。

多くのGUIアプリは$ HOME / .xsession-errorsに書き込むため、出力を確認するのに適した場所です。

apportはおそらく、良いデバッグ情報を取得するための最も確実な方法であるというmacoの権利です。ただし、クラッシュを捕捉できない場合があります。

他のすべてが失敗した場合は、gdbでアプリを実行して、情報を強制的に削除することもできます。次のようになります。

$ gdb my-app

(gdb) run

...クラッシュさせるために必要なことは何でもします...

(gdb) bt full

そしてそこから行きます。

前述のように、gdbルートを使用する場合は、シンボルもインストールする必要があります。手持ちのアドバイスについては、https： //wiki.ubuntu.com/DebuggingProgramCrashを参照してください。

あなたがに行くことができます/var/log/messages or crashes、あなたが実行することができgrep、それらの上でコマンドをし、ファイルを探していることは非常に大きな、時にはを得ることができ、アプリケーションを検索します。アプリケーションに関連する情報が返されます。:)

.desktopランチャーファイルからアプリケーションを起動する場合は、.desktopファイルにオプションTerminal=trueを追加します。これにより、プログラムを実行するとターミナルが開きます。ターミナルでの出力は、最初にコマンドラインを介してプログラムを実行した場合に表示されるものに似ています。このようにして、GUIがクラッシュまたはハングしたときに、それまでのテキスト出力を確認できます。