メールシステムの部品をデバッグする方法が書かれています。大量の詳細なログを書かせることから、コールトレーサやデバッガの管理下でデーモンプロセスを動かすことまで様々です。マシン上でのこのディレクトリの実際の場所を見つけるには、"postconfconfig_directory"コマンドが使えます。全ての配送の失敗や成功をログファイルに記録します。ファイルで定義されます。重要なメッセージは出力の「最初」の近くです。後に出てくるエラーメッセージはあまり役に立ちません。プログラマのみが修正できるソフトウェア自身の問題を示しています。これが修復されるまで処理できません。ファイルがなかったり不正なパーミション、間違った設定ファイルの設定などの、あなたが修正できる問題の結果です。これが修復されるまで処理できません。致命的または非致命的エラー状態です。これが修復されるまで処理できません。非致命的エラーを示しています。サーバなどの)問題がありますが、後で問題になるローカル設定エラーも示すかもしれません。デバッグ用メール配送レポートを生成させることができます。サーバの応答なども示します。何が起こるかを報告しますが、実際にメールは配送しません。サーバからの応答を含む成功や失敗を報告します。配送エージェントが生成した情報が含まれます。接触を持たないため、結果はテストメッセージの送信者にメールとして送られます。これらのレポートの書式は通常の非配送通知と事実上同じ書式です。メール配送状態レポートの詳細な例は、ADDRESS_REWRITING_READMEドキュメントの最後にあるデバッグセクションを参照してください。動作を有効にしてしまうことです。デーモンプロセスを失敗させてしまいます。動作が無効になっていないプロセスを探します。ファイルのコピーを保存し、問題のエントリを修正します。コマンドを実行した後で問題がなくなっていることを確認します。動作を無効にすることで問題がなくなったらおめでとう。動かし続けるのが適しています。ファイルで参照してください。パラメータにリモートのサイト名またはアドレスをリストアップします。コマンドを実行します。tcpdumpを使います。オプションで十分に大きなバッファを指定する必要があります。しないと、パケットペイロードの一部もしくは全てを失うことになります。ユーティリティを使います。デーモンでログに記録します。サーバをより饒舌にします。lmtp(8)、local(8)、pipe(8)、smtp(8)、virtual(8)配送エージェントに指定します。デーモンプロセスをマニュアルでトレースする多くのシステムでは、システムコールトレーサを使って動いているプロセスを調べることができます。4.4BSD)より参考になるのはシステムライブラリコールのトレースです。(Solaris)詳細はシステムのドキュメントを参照してください。動いているプロセスのトレースはプロセスがしようとしていることに関する脆弱な情報を与えます。後のセクションに記述されているように、これはインタラクティブデバッガプログラムを動かさずに得られるのと同じくらいの量の情報です。デーモンプロセスの起動時にいつでもコールトレーサを取り付けることができます。コールトレーサにはいくつかの種類があります。ようなコールトレーサ。これらはプロセスとカーネルの間の通信を表示します。ようなライブラリコールトレーサ。これらはライブラリルーチンのコールを表示し、プロセスの中で起ころうとしていることをよりわかりやすく示します。疑わしいコマンドに加えます。タイプして、ログファイルを監視します。インストールされているなら、xxgdbのようなインタラクティブデバッガが便利です。エクスポートしてください。疑わしいデーモンに加えます。システムを止めて、それから起動してください。設定で動くのに必要です。疑わしいデーモンプロセスが起動されるたびに、デバッガウィンドウがポップアップし、起こっていることを詳細に監視できます。デバッガを非インタラクティブモードで動かしてみて、プロセスがクラッシュしたときにスタックトレースを表示させます。疑わしいデーモンに加えます。smtpd.12345.log)。ログファイルに書かれます。よって表される振る舞いがソースコードに合わない場合が時々あります。作者によって与えられた指示からプログラムが逸れるのでしょうか?2つの可能性があります。コンパイラが過ちを犯した。これは滅多に起こりません。ハードウェアが過ちを犯した。メモリを持っていますか?どちらの場合も、実行されたプログラムは想定された動作をするプログラムではないため、何でも起こり得ます。ハードウェア関連の不具合は、電源を入れ直したりシステムを再起動すると、たいていの場合全く同じようには再現しません。できることはほとんどありません。最低限メモリエラーを検出できるハードウェアを使うようにしてください。ビットエラーに当たるのをただ待っているだけです。重要なシステムは本物のハードウェアで構成すべきです。コンパイラがエラーを作ると、プログラムが実行されるたびに問題が再現します。コンパイラのエラーはコード最適化で最もよく起こります。再構築して最適化で違いがでていないか確認する価値があります。install問題がなくなれば、そろそろベンダに助けを求める時間です。十分な情報を出せばとても助けになります。これらのボランティアの人たちは喜んで助けてくれますが、彼らの時間は限られていることを忘れないでください。問題を報告する際には、以下の情報を含めるようにしてください。「あなたが」間違っていると信じていることの説明を付けずにログだけを送ることはしないでください。完全なエラーメッセージ。記憶から情報を読み上げるのではなく、カットアンドペーストを使うか添付を使ってください。ログが保管されている場所を探すには、DEBUG_READMEドキュメントの最初の文を参照してください。ログに禁則処理をかけて助けてくれる人をイライラさせないでください。罪のない人々のEメールアドレスやパスワードを晒す必要をなくすため、テストEメールアドレスを使うことを考えてください。テストEメールアドレスを使えないのであれば、情報を一貫して匿名化してください。助けてくれる人が構文エラーを認識できるようになります。出力を送らないでください。ツールの出力を出すとさらによいです。ツールの出力を含めることを考えてください。ツールの出力を含めることを考えてみてください。セッションを記録することを考えてみてください。