web-dev-qa-db-ja.com

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

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

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

log
12
Strae

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

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

標準ログファイルの場所についての詳細 を読みたいかもしれません。

12
David Z

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

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

5
maco

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

3
qbi

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

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

apportはおそらく、良いデバッグ情報を得るための最も確実な方法であるというmacoの権利。ただし、クラッシュをキャプチャしないこともあります。

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

$ gdb my-app

(gdb) run

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

(gdb) bt full

そこから行きます。

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

2
Bryce

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

1
myusuf3

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

1
Selah