問題を診断するためのベストプラクティス[終了]

Linux / Unixユーザーとして、私たちは頻繁に問題に遭遇します。そして、長時間の問題解決の後、私たちはデバッグのスキルを身につけます。

さて、一般的なUNIXの問題をデバッグしようとするときの良い原則、方法、またはベストプラクティスは何ですか？

問題の原因を簡単に見つけるために、平均的なユーザーとしてどのようなツールが必要ですか？

方法は問題の種類によって異なります。

一般的に、Eric S. RaymondとRick Moenによる「スマートな方法で質問する方法」は、問題に焦点を当て、問題の重要な部分について考えたかどうかを確認するのに役立つアドバイスです。

デバッグ中の最初の情報源は、システム/アプリケーションが書き込むログファイルです。それらの一般的な場所は、ターミナルまたはのファイルです/var/log/。多くのアプリケーションはさまざまなタイプのログレベルをサポートしており、使用可能なメッセージが見つからない場合は増やす必要があります。多くの場合、-vより多くのメッセージを取得するための詳細スイッチがあります。

まだ何も使えませんか？設定ファイル、アプリケーションで必要なファイルの権限を確認してください/etc/syslog-ng.conf。たとえば、システムロガーの設定を変更する必要があるかもしれません。

エラーメッセージがある場合、グーグル検索を行うと、多くの場合、メッセージボードのエントリや、その背後にある問題について議論するUsenetの投稿が表示されます。あなたはそこに解決策を見つけることができる可能性が高いです。プロジェクトユーザーのメーリングリスト、メッセージボード、IRCチャネルも非常に役立ちます。

アプリケーションがメッセージなしでクラッシュすることがあります。コードの読み取りと変更の他に、アプリケーションフローを発見するための優れたツールがありstraceます。

このツールは、システムコールとシグナルをトレースします。アプリケーションでエラーが検出されても、systraceで問題を発見できます。

別のアプローチは、を使用してアプリケーションをデバッグすることですgdb。これを使用するには、上級ユーザーであり、何をすべきかを知っている必要があります。

デバッグのための単一の一般原則が必要な場合は、次のようになります。システムがどのように機能するかをできるだけ理解します。システムの各コンポーネント、および各コンポーネントの障害モードを理解します。最近変更したコンポーネントと、自分で変更または失敗したコンポーネントに注意してください。

詳細を探していた場合、echoxの回答には多くの優れた情報が含まれています。

私の意見では、David Agansがデバッグに関する非常に優れた本を書いています。また、デバッグのための一連のガイドラインも含まれていました。

その上、一般的な（ドメイン）知識と経験は、パターンを確認する上で非常に役立ちます。物事がどのように構築されているかを調べ、分解します。定期メンテナンスを実施してください。あいまいな実験を設定します。読む、読む、読む。ものを作る。常に書きます。問題を抱えている他の人々を助けます。あなたの戦いを選んでください。冷静さを保つ。スマイル。:)