1 - この文書の目的 ================== この文書はソフトウェアのたくさんの詳細なログを syslog デーモンに 生成したり、インタラクティブなデバッガの管理下でいくつかのデーモン プロセスを走らせることによる、Postfix メールシステムの部品の デバッグ方法を記述します。 2 - 特定の SMTP 接続に対する冗長なロギング ========================================== /etc/postfix/main.cf で、リモートサイトの名前やアドレスを "debug_peer_list" パラメータに列挙します。例えば、ループバック インターフェースからの接続やループバックインターフェースへの 接続に対してたくさんの情報をソフトウェアログに syslog デーモンに 記録するには次のようにします: debug_peer_list = 127.0.0.1 一つもしくはそれ以上のホストやドメイン、アドレス、net/mask を 指定することができます。 2b - sniffer で SMTP 接続を記録する =================================== この例では tcpdump を使います。会話を記録するために大きな バッファを指定する必要があります。そうしないと、一部もしくは 全てのパケットペイロードを失うかもしれません。 tcpdump -w /file/name -s 2000 host hostname and port 25 しばらくこれを走らせ、終わったら Ctrl-C で止めます。データを 見るためには、バイナリビュアーや ftp://ftp.porcupine.org/pub/debugging から入手できる、私の tcpdumpx ユーティリティを使ってください。 3 - Postfix デーモンプログラムをより冗長にする ============================================== /etc/postfix/master.cf の選択したデーモンの定義に、一つもしくは それ以上の -v オプションを付け、"postfix reload" をタイプします。 これはたくさんの活動のログを syslog デーモンに記録するようにします。 4 - マニュアルで Postfix デーモンプロセスをトレースする ======================================================= システムコールトレーサを使って動いているプロセスを調べることが できるシステムもあります。例: # trace -p process-id (SunOS 4) # strace -p process-id (Linux and many others) # truss -p process-id (Solaris, FreeBSD) # ktrace -p process-id (generic 4.4BSD) さらに有益なのは、システムライブラリコールのトレースです。例: # ltrace -p process-id (Linux, also ported to FreeBSD and BSD/OS) # sotruss -p process-id (Solaris) 詳細はシステムのドキュメントを参照してください。 動いているプロセスのトレースは、プロセスが何をしようとしているか について、攻撃可能な情報を与えることがあります。 後のセクションで記述するように、 これはインタラクティブな デバッガプログラムを走らせずに得られるのと同じだけの情報です。 5 - Postfix デーモンプロセスを自動的にトレースする ================================================== Postfix はデーモンプロセスをスタートする時にいつでもコール トレーサを付けることができます。コールトレーサにはいくつかの 種類があります。 1) trace や truss、strace、ktrace のようなシステムコールトレーサ。 これらはプロセスとカーネルの間の通信を見せます。 2) ltrace のようなライブラリコールトレーサ。これらはライブラリ ルーチンのコールを見せたり、プロセス内で起こっていることの よりよいアイディアを与えます。 /etc/postfix/master.cf の疑わしいコマンドに -D オプションを 次の例のように付け加えます: smtp inet n - n - - smtpd -D 選択したコールトレーサを呼び出すためには /etc/postfix/main.cf の debugger_command 定義を、例えば次のように編集します: debugger_command = PATH=/bin:/usr/bin:/usr/local/bin (truss -p $process_id 2>&1 | logger -p mail.info) & sleep 5 "postfix reload" をタイプし、ログファイルを監視してください。 6 - デバッガの下でデーモンプログラムを走らせる ============================================== /etc/postfix/master.cf の疑わしいコマンドに -D オプションを 次の例のように付け加えます: smtp inet n - n - - smtpd -D 選択したデバッガを呼び出すためには /etc/postfix/main.cf の debugger_command 定義を編集します。 2つの方法を詳細に示します: 1) Postfix マシンに X Windows をインストールしていなかったり、 インタラクティブデバッガになじみがなければ、非インタラクティブ モードの gdb を走らせてみましょう: /etc/postfix/main.cf: -------------------- debugger_command = PATH=/bin:/usr/bin:/usr/local/bin; export PATH; (echo cont; echo where) | gdb $daemon_directory/$process_name $process_id 2>&1 >$config_directory/$process_name.$process_id.log & sleep 5 設定の変更を有効にするために "postfix reload" をタイプして ください。 デーモンプロセスの調査が始まると、毎回デーモンとプロセス ID に ちなんだ (例えば smtpd.12345.log) 名前のファイルが作られます。 プロセスがクラッシュすると、スタックトレース (と "where" コマンドの 出力) がこのログファイルに書かれます。 2) Postfix マシンに X Windows がインストールされているのであれば、 xxgdb のようなインタラクティブデバッガが便利です。 /etc/postfix/main.cf: -------------------- debugger_command = PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin xxgdb $daemon_directory/$process_name $process_id & sleep 5 gdb がコマンドサーチパスに含まれていることを確かめ、X アクセス コントロールが働くように、XAUTHORITY を、例えば次のように export してください: % setenv XAUTHORITY ~/.Xauthority Postfix システムを停止してから起動します。これは Postfix が 正しい XAUTHORITY および DISPLAY 設定で動くために必要です。 疑わしいデーモンプロセスが起動するたびに、デバッガウインドウが ポップアップし、何が起こっているかの詳細を見ることができるか (xxgdb 使用時)、ファイルが作られます (非インタラクティブモードの gdb 使用時)。 7 - 不正な動作 ============== Postfix によって現される動作がソースコードに合わないことが あります。なぜ作者が指示したことからプログラムが外れるのでしょう? 2つの可能性があります。 1 - コンパイラが混乱している。 2 - ハードウェアが混乱している。 どちらの場合も、実行されているプログラムは、実行することが 期待されているプログラムではなく、どんなことでも起こり得ます。 3つ目の可能性もあります: 3 - システムソフトウェア(カーネルやライブラリ)のバグ。 ハードウェアに関連した欠陥は不規則に起こり、電源を切ってシステムを 再起動すると、たいていは再び起こりません。悪いハードウェアに ついてできることはほとんどありません。最低限、メモリエラーを 検出できるハードウェアを使うように気を付けてください。そうでなければ、 Postfix はビットエラーに撃たれるのを待っているよいカモと なるでしょう。クリティカルなシステムは実在のハードウェアに 値します。 コンパイラが混乱していると、その結果のプログラムが走ると いつも問題が起こります。コンパイラのエラーはほとんどの場合コード 最適化で起こっているようです。電源を切ってシステムを再起動しても 問題が再び起こるのであれば、最適化を行なわずに Postfix を 再構築して、最適化が差を生み出しているかを見る価値があるかも しれません。 最適化を切って Postfix をコンパイルするには、次のようにします: % make tidy % make makefiles OPT= これはコンパイラに最適化を要求しない Makefile 群を生成します。 makefile が準備できたら、ソフトウェアをビルドします: % make % su # make install そして問題が再び起こるかを見ます。もし問題がなくなれば、ベンダーに 話してください。