Sun Java System Messaging Server 6 2005Q4 管理ガイド

MTA メッセージおよび接続のログの管理

MTA は、メッセージがキューに出し入れされるたびにログを作成することができます。また、ディスパッチャーエラーとデバッグ出力も生成できます。

チャネルごとにログを制御したり、すべてのチャネル上のメッセージアクティビティーのログを記録するよう指定することができます。初期設定では、すべてのチャネルでのログ記録が無効になっています。

詳細は、「MTA ログを有効にする」を参照してください。

ログを有効にすると、メッセージが MTA チャネルを通過するたびに msg_svr_base/data/log/mail* ファイルにエントリが書き込まれます。そのようなログエントリは、MTA (または特定のチャネル) を通過するメッセージの数についての統計情報を収集するのに役立ちます。それらのログエントリを使用して、メッセージが送信または配信されたかどうか、またいつ送信または配信されたかなどのその他の問題も調査できます。

毎晩午前 0 時頃に実行されるメッセージ返送ジョブは、累積されたログファイル mail.log に既存の mail.log_yesterday を追加し、現在の mail.log_current ファイルの名前を mail.log_yesterday に変更してから、新しい mail.log_current ファイルを開始します。また、connection.log* ファイルに対しても同様の処理が行われます。

MTA は自動的にロールオーバーを実行して現在のファイルを維持しますが、エントリが累積される mail.log ファイルは、ファイルのバックアップ、切り捨て、削除などのタスクのポリシーを決めて管理する必要があります。

ログファイルの管理方法を検討するときは、MTA の定期的な返送ジョブが、サイトが提供する msg_svr_base/bin/daily_cleanup プロシージャー (存在する場合) を実行することに注意してください。このため、サイトによっては独自のクリーンアップ方法を提供していることもあります。たとえば、古い mail.log ファイルの名前を週に 1 回 (または月に 1 回) 変更するなどです。


注 –

ログが有効になっていると、mail.log ファイルが大きくなり続けるため、そのままにしておくと利用可能なディスク容量がなくなってしまいます。このファイルのサイズを監視し、定期的に不要なコンテンツを削除してください。ファイル全体を削除することもできます。この場合、必要に応じて新しいファイルが作成されます。


MTA ログエントリの形式について

MTA ログファイルは、ASCII テキストとして記述されます。デフォルトでは、次に示すように、各ログファイルエントリには 8 個または 9 個のフィールドがあります。

19-Jan-1998 19:16:57.64 l tcp_local E 1 adam@sesta.com rfc822;marlowe@siroe.com marlowe@siroe.com

ログエントリには以下の情報が含まれています。

  1. エントリが記録された日付と時刻 (上の例では 19-Jan-1998 19:16:57.64)。

  2. ソースチャネルのチャネル名 (上の例では l)。

  3. 宛先チャネルのチャネル名 (上の例では tcp_local)。SMTP チャネルの場合、LOG_CONNECTION が有効になっているときは、プラス記号「+」が SMTP サーバーの受信を示し、マイナス記号「-」が SMTP クライアント経由の送信を示します。

  4. エントリのタイプ (上の例では E)。表 21–2 を参照。

  5. メッセージのサイズ (上の例では 1)。デフォルトでは K バイト単位で表されますが、MTA オプションファイルで BLOCK_SIZE キーワードを使用して単位を変更することもできます。

  6. エンベロープ From: アドレス (上の例では adam@sesta.com)。通知メッセージのようにエンベロープ From: アドレスが空のメッセージの場合、このフィールドは空白です。

  7. エンベロープ To: アドレスの元の形式 (上の例では marlowe@siroe.com)。

  8. エンベロープ To: アドレスの元の形式 (上の例では marlowe@siroe.com)。

  9. 配信ステータス (SMTP チャネルのみ)。

次の表に、ログエントリコードの説明を示します。

表 21–2 ログエントリのコード

エントリ 

説明 

不良コマンドが SMTP サーバーに送信されました。受取人アドレスフィールドには拒否されたコマンドが、診断フィールドには SMTP サーバーからの応答が含まれます。MTA チャネルオプションの MAX_B_ENTRIES は、特定のセッションでログされる不良コマンドの数を制御します。デフォルトは 10 です。 

BA 

トランザクションの前の方で認証が成功したあとの不良コマンドです。 

BS 

TLS の起動に成功したあとの不良コマンドです。 

BSA 

TLS や AUTH での不良コマンドです。 

キューからの取り出しに成功しました 

DA 

SASL (認証) でのキューからの取り出しに成功しました 

DS 

TLS (セキュリティー) でのキューからの取り出しに成功しました 

DSA 

TLS および SASL (セキュリティーと認証) でのキューからの取り出しに成功しました 

キューに入れます 

EA 

SASL (認証) でキューに入れることに成功しました 

ES 

TLS (セキュリティー) でキューに入れることに成功しました 

ESA 

TLS および SASL (セキュリティーと認証) でキューに入れることに成功しました 

キューに入れる試行が拒否されました (スレーブチャネルプログラムによる拒否) 

受取メッセージが拒否されました。差出人が NOTIFY=NEVER DSN フラグの設定を要求した場合、メッセージがタイムアウトになった場合、またはメッセージが手動で返された場合です。たとえば、imsimta qm “delete” コマ ンドは常に各受取人の「K」レコードを生成しますが、qm “return” コマ ンドが「R」レコードではなく「K」レコードを生成する場合です。これは、差出人自身の要求によって、通知が差出人に送信されなかったことを示します。

これは、同じ種類の拒否またはタイムアウトである「R」レコードと比較できますが、「R」レコードでは、この失敗したメッセージに関して、元の差出人に戻される新しい通知メッセージも生成されます。 

キューからの取り出しで一時的に失敗しました 

キューからの取り出し試行で受取人アドレスが拒否され (マスターチャネルプログラムによる拒否)、失敗またはバウンスメッセージが生成されました 

トランザクションが異常終了したときに表示される警告メッセージです。キューに入れられた受取人アドレスごとに、V レコードは 1 つになります。 

メッセージはまだ配信されていませんが、キューに残っていて再配信が試行されていることを元の差出人に通知するために送信された警告メッセージです。 

数人の受取人に対しては成功しましたが、この受取人に対しては一時的に失敗しました。すべての受取人の元のメッセージファイルはキューから取り出され、それに代わって新しいメッセージファイルが入れられ、その他の失敗した受取人がすぐにキューに入れられます 

SMTP チャネルの LOG_CONNECTION + または ? エントリ 

接続が終了しました。診断フィールドがあとに続きます。connection.log_current (ログファイルが 1 つしか使用されない場合は mail.log_current) に書き込まれます。接続が終了した理由を記録するために使用されます。特に、なんらかのセッション切断制限に達したために接続が終了した場合は、その情報が診断フィールドに表示されます。 

接続が開始しました 

ログの SMTP 認証が成功および失敗しました。形式はほかの O エントリや C エントリと同じです。特に、同じアプリケーションや転送情報のフィールドが同じ順序で表示されます。ユーザー名が明らかな場合は、ユーザー名フィールドに記録されます。このエントリは、LOG_CONNECTION MTA オプションのビット 7 (値は 128) によって制御されます。 

接続が拒否されました 

接続が確立される前に試行に失敗しました 

ETRN コマンドを受信しました 

LOG_CONNECTIONLOG_FILENAMELOG_MESSAGE_IDLOG_NOTARYLOG_PROCESS、および LOG_USERNAME がすべて MTA オプションファイルで有効になっている場合、形式は次に示されているようになります。この例のログエントリ行は改行されて表示されていますが、実際のログエントリは 1 行で記述されます。


19-Jan-1998 13:13:27.10 HOSTA   2e2d.2.1 tcp_local   l
 E 1 service@siroe.com rfc822;adam@sesta.com
 adam 276 /imta/queue/l/ZZ01IWFY9ELGWM00094D.00
 <01IWFVYLGTS499EC9Y@siroe.com> inetmail
 siroe.com (siroe.com [192.160.253.66])
                  

前述の説明に含まれていない追加のフィールドは、以下のとおりです。

  1. チャネルプロセスを実行しているノードの名前 (例では HOSTA)。

  2. プロセス ID (16 進数) と、その後ろに続くピリオド (ドット) 文字と数。これがマルチスレッドチャネルエントリ (つまり、tcp_* チャネルエントリ) であった場合、プロセス ID と数の間にスレッド ID も存在します。この例では、プロセス ID は 2e2d.2.1 です。

  3. メッセージの NOTARY (配達証明書要求) フラグ。整数値で表記 (例では 276) します。

  4. MTA キュー領域内のファイル名 (例では /imta/queue/l/ZZ01IWFY9ELGWM00094D.00)。

  5. メッセージ ID (例では <01IWFVYLGTS499EC9Y@siroe.com>)。

  6. 実行プロセスの名前 (例では inetmail)。UNIX での SMTP サーバーなどのディスパッチャープロセスの場合、通常は inetmail (SASL を使用しなかった場合) になります。

  7. 接続情報 (例では siroe.com (siroe.com [192.160.253.66]))。接続情報は、送信システムが HELO/EHLO 行に示す名前 (着信 SMTP メッセージの場合) や、チャネルの正規のホスト名 (ほかの種類のチャネルの場合) など、送信システムまたはチャネル名で構成されています。TCP/IP チャネルの場合、送信システムの「実際の」名前、つまり、DNS リバース検索によってレポートされるシンボリック名や IP アドレスは、ident* チャネルキーワードを使用して括弧内にレポートすることもできます。「IDENT 検索」を参照してください。この例は、DNS によって見つかった名前と IP アドレスの両方を表示するように指定するキーワードの 1 つ ( たとえば、デフォルトの identnone キーワード) が使用されていると仮定しています。

MTA ログを有効にする

少数の特定の MTA チャネルの統計情報を収集するには、対象となる MTA チャネルのみのログチャネルキーワードを有効にします。ほとんどのサイトでは、すべての MTA チャネルでのログを有効にしています。特に、問題を突き止める場合、問題を診断する最初のステップは、メッセージが意図していたチャネルに送られているかどうかに注目することです。すべてのチャネルに対してログを有効にしておくと、このような問題を調べる際に役立ちます。

Procedure特定のチャネルの MTA のログを有効にする

手順
  1. imta.cnf ファイルを編集します。

    このファイルは /opt/SUNWmsgsr/config ディレクトリにあります。

  2. 特定のチャネルに対してログの作成を有効にするには、チャネル定義で logging キーワードを追加します。例:


    channel-name keyword1 keyword2 logging
    

    また、ログファイルやログレベルなどのディレクトリパスのような設定パラメータの数も、設定することができます。「メッセージストア、管理、およびデフォルトのサービスログの管理」を参照してください。

Procedureすべてのチャネルの MTA ログを有効にする

手順
  1. imta.cnf ファイルを編集します。

    このファイルは /opt/SUNWmsgsr/config ディレクトリにあります。

  2. defaults チャネルにログキーワードを追加します (「チャネルのデフォルトを設定する」を参照)。例:


    defaults logging notices 1 2 4 7 copywarnpost copysendpost postheadonly 
    noswitchchannel immnonurgent maxjobs 7 defaulthost siroe.com
    
    l defragment charset7 us-ascii charset8 iso-8859-01
    siroe.com

その他の MTA ログオプションの指定

ログが有効になっているときに与えられる基本的な情報のほかにも、MTA オプションファイルにさまざまな LOG_*MTAオプションを設定することにより、オプションの情報フィールドを含めることができます。IMTA テイラーファイル (msg_svr_base/config/imta_tailor) の IMTA_OPTION_FILE オプションで指定されたファイルで、MTA オプションファイルを指定します。デフォルトでは、これは msg_svr_base/config/option.dat ファイルです。

MTA オプションファイルの詳細は、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』「Option File」を参照してください。

ProcedureMTA ログを syslog へ送信する

手順
  1. MTA オプションファイルを編集します。

  2. LOG_MESSAGES_SYSLOG オプションを 1 に設定します。

    0 の値はデフォルトであり、syslog (イベントログ) のログが実行されなかったことを示します。

Procedureログメッセージエントリを関連付ける

手順
  1. MTA オプションファイルを編集します。

  2. LOG_MESSAGE_ID オプションを 1 に設定します。

    0 の値はデフォルトであり、メッセージ ID が mail.log ファイルに保存されなかったことを示します。

Procedureメッセージの配信再試行を確認する

手順
  1. MTA オプションファイルを編集します。

  2. LOG_FILENAME オプションを 1 に設定します。

    このオプションを使用すると、特定のメッセージファイルの配信が何回再試行されたかを即座に簡単に確認できます。このオプションは、MTA が複数の受信者へのメッセージをディスク上で別々のメッセージファイルコピーに分割する場合としない場合を把握するのにも役立ちます。

ProcedureTCP/IP 接続のログを記録する

手順
  1. MTA オプションファイルを編集します。

  2. LOG_CONNECTION オプションを設定します。

    このオプションを使用すると、MTA は TCP/IP 接続とメッセージトラフィックのログを記録します。接続ログエントリは、デフォルトで mail.log* ファイルに書き込まれます。さらに、接続ログエントリを connection.log* ファイルに書き込むことも可能です。詳細は、SEPARATE_CONNECTION_LOG オプションを参照してください。

Procedureconnection.log ファイルにエントリを書き込む

手順
  1. MTA オプションファイルを編集します。

  2. SEPARATE_CONNECTION_LOG オプションを 1 に設定します。

    このオプションを使用して、ログエントリを connection.log ファイルに代わりに書き込むことを指定できます。デフォルト値の 0 は、接続ログを MTA ログファイルに格納します。

Procedureプロセス ID でログメッセージを関連付ける

手順
  1. MTA オプションファイルを編集します。

  2. LOG_PROCESS オプションを設定します。

    LOG_CONNECTION とともに使用すると、このオプションは接続エントリとそれに対応するメッセージエントリの相関関係をプロセス ID によって示すことができます。

Procedureメールを mail.log ファイルのキューに入れるプロセスに関連付けられたユーザー名を保存する

手順
  1. MTA オプションファイルを編集します。

  2. LOG_USERNAME オプションを設定します。

    このオプションは、メールをキューに入れるプロセスに関連付けられたユーザー名を mail.log ファイルに保存するかどうかを制御します。SASL (SMTP AUTH) を使用している SMTP 送信の場合は、ユーザー名フィールドが認証ユーザー名 (プレフィックスとしてアスタリスクが付いたもの) になります。

MTA メッセージログの例

MTA メッセージファイルに記録されるフィールドの形式とフィールドのリストは、設定したログオプションによって異なります。ここでは、いくつかの典型的なログエントリの解釈の例を示します。その他のオプションのフィールドについては、「その他の MTA ログオプションの指定」を参照してください。


注 –

ここではログファイルエントリが複数行にわたって表示されていますが、実際のログファイルエントリは 1 行で記述されます。


ログファイルを確認するときは、通常のシステムでは一度に多くのメッセージが処理されていることに留意してください。通常、特定のメッセージに関連するエントリは、同時に処理されているその他のメッセージに関連するエントリの間に散らばっています。基本的なログ情報は、MTA を通過するメッセージの数が全部でいくつあるかを把握するのに役立ちます。

同じ受取人への同じメッセージに関連する特定のエントリを関連付ける場合は、LOG_MESSAGE_ID を有効にします。特定のメッセージを MTA キュー領域にある特定のファイルと関連付けたり、エントリを見てキューからの取り出しに成功していない特定のメッセージの配信を何回試行したかを確認する場合は、LOG_FILENAME を有効にします。SMTP メッセージ (TCP/IP チャネル経由で処理されるメッセージ) の場合、リモートシステムとの TCP 接続を送信メッセージと関連付けるには、LOG_PROCESS と何らかのレベルの LOG_CONNECTION を有効にします。

MTA ログの例: ユーザーがメッセージを送信する場合

ローカルユーザーが送信 TCP/IP チャネルからインターネットなどにメッセージを送信する場合に見られる、基本的なログエントリの例を次に示します。この例では、LOG_CONNECTION が有効になっています。(1) と (2) の行は 1 つのエントリで、実際のログファイルでは 1 行で記述されます。同様に、(3) 〜 (7) の行も 1 つのエントリで、実際のログファイルでは 1 行で記述されます。


例 21–1 MTA ログ: ローカルユーザーが送信メッセージを送った場合


19-Jan-1998 19:16:57.64 l            tcp_local    E 1         (1)
 adam@sesta.com rfc822;marlowe@siroe.com marlowe@siroe.com     (2)
 
 19-Jan-1998 19:17:01.16 tcp_local                  D 1        (3)
 adam@sesta.com rfc822;marlowe@siroe.com marlowe@siroe.com     (4)
 dns;thor.siroe.com
 (TCP|206.184.139.12|2788|192.160.253.66|25)                   (5)
 (THOR.SIROE.COM -- Server ESMTP [iMS V5.0 #8694])             (6)
 smtp;250 2.1.5 marlowe@siroe.com and options OK.              (7)
  1. この行は、1 ブロック (1) メッセージをチャネル l からチャネル tcp_local のキューに入れた (E) ときの日付と時刻を示します。

  2. この部分は、実際にはログファイルでは (1) と同じ行に表示されます。エンベロープ From: アドレス ( この例では adam@sesta.com) と、エンベロープ To: アドレスの元のバージョンと現在のバージョン (この例では marlowe@siroe.com) を示しています。

  3. 1 ブロック (1) メッセージを tcp_local チャネルのキューから取り出した (D) ときの日付と時刻を示しています。つまり、tcp_local チャネルがリモートの SMTP サーバーへの送信に成功したことを示しています。

  4. エンベロープ From: アドレス、元のエンベロープ To: アドレス、および現在の形式のエンベロープ To: アドレスを示しています。

  5. 接続先の実際のシステムの名前が DNS で thor.siroe.com であること、ローカルの送信システムの IP アドレスが 206.184.139.12 で、ポート 2788 から送信されていること、リモートの宛先システムの IP アドレスが 192.160.253.66 で、接続ポートが 25 であることを示しています。

  6. リモートの SMTP サーバーの SMTP 見出し行を示しています。

  7. このアドレスに返された SMTP ステータスコードを示しています。250 は基本的な SMTP 成功コードであり、このリモート SMTP サーバーは拡張 SMTP ステータスコードと追加テキストで応答しています。


MTA ログの例: オプションのログフィールドを含む場合

これは、例 21–3 に示されているログエントリと似ていますが、LOG_MESSAGE_ID=1 を設定することによりファイル名とメッセージ ID も記録されています。(1) と (2) を参照してください。特に、メッセージ ID は、エントリとそれに関連するメッセージの相関関係を示すために使われます。


例 21–2 MTA ログ: オプションのログフィールドを含む場合


19-Jan-1998 19:16:57.64 l            tcp_local    E 1
  adam@sesta.com rfc822;marlowe@siroe.com marlowe@siroe.com
  /imta/queue/tcp_local/ZZ01ISKLSKLZLI90N15M.00
   <01ISKLSKC2QC90N15M@sesta.com>    (1)
                  
 19-Jan-1998 19:17:01.16 tcp_local                  D 1
  adam@sesta.com rfc822;marlowe@siroe.com marlowe@siroe.com
  /imta/queue/tcp_local/Z01ISKLSKLZLI90N15M.00
    <01ISKLSKC2QC90N15M@sesta.com>   (2)
  dns;thor.siroe.com (TCP|206.184.139.12|2788|192.160.253.66|25)
  (THOR.SIROE.COM -- Server ESMTP [iMS V5.0 #8694])
  smtp;250 2.1.5 marlowe@siroe.com and options OK.

MTA ログの例: リストに送信する場合

この例は、LOG_FILENAME=1LOG_MESSAGE_ID=1、および LOG_CONNECTION=1 を有効にして、複数の受取人に送信する例を示しています。ここでは、ユーザー adam@sesta.com が MTA メーリングリスト test-list@sesta.com に送信し、それが bob@sesta.comcarol@varrius.com、および david@varrius.com に展開されています。それぞれの受取人の元のエンベロープ To: アドレスは test-list@sesta.com ですが、現在のエンベロープ To: アドレスは受取人ごとに異なるアドレスであることに注意してください。2 つのファイル (チャネル l と送信チャネル tcp_local 用) がありますが、メッセージ ID は同じです。


例 21–3 MTA ログ: リストに送信する場合


19-Jan-1998 20:01:44.10 l    l                    E 1
  adam@sesta.com rfc822;test-list@sesta.com bob
  imta/queue/l/ZZ01ISKND3DE1K90N15M.00
  <01ISKND2H8MS90N15M@sesta.com>
 
 19-Jan-1998 20:01:44.81 l            tcp_local    E 1
  adam@sesta.com rfc822;test-list@sesta.com carol@varrius.com
  imta/queue/tcp_local/ZZ01ISKND2WS1I90N15M.00 
  <01ISKND2H8MS90N15M@sesta.com>
 
 19-Jan-1998 20:01:44.81 l            tcp_local    E 1
  adam@sesta.com rfc822;test-list@sesta.com david@varrius.com
  imta/queue/tcp_local/ZZ01ISKND2WS1I90N15M.00
 <01ISKND2H8MS90N15M@sesta.com>
 
 19-Jan-1998 20:01:50.69 l                         D 1
  adam@sesta.com rfc822;test-list@sesta.com bob
  imta/queue/l/ZZ01ISKND3DE1K90N15M.00
  <01ISKND2H8MS90N15M@sesta.com>
 
 19-Jan-1998 20:01:57.36 tcp_local                  D 1
  adam@sesta.com rfc822;test-list@sesta.com carol@varrius.com
  imta/queue/tcp_local/ZZ01ISKND2WS1I90N15M.00
  <01ISKND2H8MS90N15M@sesta.com>
  dns;gw.varrius.com (TCP|206.184.139.12|2788|192.160.253.66|25)
  (gw.varrius.com -- SMTP Sendmail)
  smtp;250 OK.
 
 19-Jan-1998 20:02:06.14 tcp_local                  D 1
  adam@sesta.com rfc822;test-list@sesta.com david@varrius.com
  imta/queue/tcp_local/ZZ01ISKND2WS1I90N15M.00
  <01ISKND2H8MS90N15M@sesta.com>
  dns;gw.varrius.com (TCP|206.184.139.12|2788|192.160.253.66|25)
  (gw.varrius.com -- SMTP Sendmail)
  smtp;250 OK.

MTA ログ: 存在しないドメインに送信する場合

この例では、存在しないドメイン (ここでは very.bogus.com) への送信の試行を示しています。つまり、存在しないことが MTA の書き換えルールによって通知されないドメイン名であり、また、送信 TCP/IP チャネルに一致するドメイン名に送信しようとしました。この例では、LOG_FILENAME=1LOG_MESSAGE_ID=1 という MTA オプションが設定されていると仮定しています。

TCP/IP チャネルが作動していて、DNS のドメイン名をチェックしているとき、DNS はそのような名前は存在しないというエラーを返します。(5) の「拒否」エントリ (R) のように DNS はエラーを返し、(6) のようにドメイン名が不正であることを示します。

メッセージが発行されたあとでアドレスが拒否されたため、MTA は元の差出人へのバウンスメッセージを生成します。MTA は新しい拒否メッセージを元の差出人のキューに入れ (1)、元の送信メッセージを削除する ((5) の R エントリ) 前にポストマスターにコピーを送信します (4)。

(2) と (8) に示すように、バウンスメッセージなどの通知メッセージには空のエンベロープ From: アドレスがあります。エンベロープ From: フィールドは空白で示されています。MTA が生成したバウンスメッセージが最初にキューに入れられることにより、新しい通知メッセージのメッセージ ID の後ろに元のメッセージのメッセージ ID が表示されます (3)(この情報は MTA で常に利用できるわけではないが、利用できる場合は、失敗した送信メッセージに対応するログエントリを、通知メッセージに対応するログエントリに関連付けることができる)。この通知メッセージは、プロセスチャネルのキューに入れられたあと、該当する宛先チャネルのキューに入れられます (7)。


例 21–4 MTA ログ: 存在しないドメインに送信する場合


19-JAN-1998 20:49:04 l            tcp_local    E 1
  adam@sesta.com rfc822;user@very.bogus.com user@very.bogus.com
  imta/queue/tcp_local/ZZ01ISKP0S0LVQ94DU0K.00
 <01ISKP0RYMAS94DU0K@SESTA.COM>
 
19-JAN-1998 20:49:33 tcp_local    process      E 1                (1)
 rfc822;adam@sesta.com adam@sesta.com                             (2)
 imta/queue/process/ZZ01ISKP0S0LVQ94DTZB.00
 <01ISKP22MW8894DTAS@SESTA.COM>,<01ISKP0RYMAS94DU0K@SESTA.COM>    (3)

19-JAN-1998 20:49:33 tcp_local    process      E 1                (4)
 rfc822;postmaster@sesta.com postmaster@sesta.com
 imta/queue/process/ZZ01ISKP0S0LVQ94DTZB.00
 <01ISKP22MW8894DTAS@SESTA.COM>,<01ISKP0RYMAS94DU0K@SESTA.COM>
 
19-JAN-1998 20:50:07 tcp_local                  R 1               (5)
 adam@sesta.com rfc822;user@very.bogus.com user@very.bogus.com
 imta/queue/tcp_local/ZZ01ISKP0S0LVQ94DU0K.00
 <01ISKP0RYMAS94DU0K@SESTA.COM>
 Illegal host/domain name found                                   (6)

19-JAN-1998 20:50:08 process      l            E 3                (7)
 rfc822;adam@sesta.com adam                                       (8)
 imta/queue/l/ZZ01ISKP23BUQS94DTYL.00
 <01ISKP22MW8894DTAS@SESTA.COM>
 
19-JAN-1998 20:50:08 process      l            E 3
  rfc822;postmaster@sesta.com postmaster
  imta/queue/l/ZZ01ISKP23BUQS94DTYL.00
 <01ISKP22MW8894DTAS@SESTA.COM>
 
19-JAN-1998 20:50:12 l                         D 3
  rfc822;adam@sesta.com adam
  imta/queue/l/ZZ01ISKP23BUQS94DTYL.00
  <01ISKP22MW8894DTAS@SESTA.COM>
 
19-JAN-1998 20:50:12 l                         D 3
  rfc822;postmaster@sesta.com postmaster
  imta/queue/l/ZZ01ISKP23BUQS94DTYL.00
  <01ISKP22MW8894DTAS@SIROE.COM>

MTA ログの例: 存在しないリモートユーザーに送信する場合

ここでは、リモートシステムの不正アドレスに送信しようとした場合の例を示します。この例では、LOG_FILENAME=1 および LOG_MESSAGE_ID=1 という MTA オプションと、LOG_BANNER=1 および LOG_TRANSPORTINFO=1 というチャネルオプションが設定されていると仮定しています。(1) の拒否エントリ (R) に注意してください。例 21–4 の拒否エントリとは異なり、この例の拒否エントリではリモートシステムに接続されたことが示されており、また、(2)、(3) にリモート SMTP サーバーが発行した SMTP エラーコードが示されています。(2) に示されている情報は、LOG_BANNER=1 および LOG_TRANSPORTINFO=1 というチャネルオプションが設定されていることを前提としています。


例 21–5 MTA ログ: 存在しないリモートユーザーに送信する場合


20-JAN-1998 13:11:05 l            tcp_local    E 1
  adam@sesta.com rfc822;nonesuch@siroe.com nonesuch@siroe.com
  imta/queue/tcp_local/ZZ01ISLNBB1JOE94DUWH.00
  <01ISLNBAWV3094DUWH@sesta.com>
 
20-JAN-1998 13:11:08 tcp_local    process      E 1
  rfc822;adam@sesta.com adam@sesta.com
  imta/queue/process/ZZ01ISLNBB1JOE94DSGB.00
  <01ISLNBFKIDS94DUJ8@sesta.com>,<01ISLNBAWV3094DUWH@sesta.com>
 
 20-JAN-1998 13:11:08 tcp_local    process      E 1
  rfc822;postmaster@sesta.com postmaster@sesta.com
  imta/queue/process/ZZ01ISLNBB1JOE94DSGB.00
  <01ISLNBFKIDS94DUJ8@sesta.com>,<01ISLNBAWV3094DUWH@sesta.com>
 
20-JAN-1998 13:11:11 tcp_local                  R 1       (1)
  adam@sesta.com rfc822;nonesuch@siroe.com nonesuch@siroe.com
  imta/queue/tcp_local/ZZ01ISLNBB1JOE94DUWH.00 
  <01ISLNBAWV3094DUWH@sesta.com>
  dns;thor.siroe.com
  (TCP|206.184.139.12|2788|192.160.253.66|25)             (2)
  (THOR.SIROE.COM -- Server ESMTP [iMS V5.0 #8694])
  smtp; 553 unknown or illegal user: nonesuch@siroe.com   (3)
 
20-JAN-1998 13:11:12 process      l            E 3
  rfc822;adam@sesta.com adam
  imta/queue/l/ZZ01ISLNBGND1094DQDP.00
  <01ISLNBFKIDS94DUJ8@sesta.com>
 
20-JAN-1998 13:11:12 process      l            E 3
  rfc822;postmaster@sesta.com postmaster
  imta/queue/l/ZZ01ISLNBGND1094DQDP.00
  <01ISLNBFKIDS94DUJ8@sesta.com>
 
20-JAN-1998 13:11:13 l                         D 3
  rfc822;adam@sesta.com adam@sesta.com
  imta/queue/l/ZZ01ISLNBGND1094DQDP.00
  <01ISLNBFKIDS94DUJ8@sesta.com>
 
20-JAN-1998 13:11:13 l                         D 3
  rfc822;postmaster@sesta.com postmaster@sesta.com
  imta/queue/l/ZZ01ISLNBGND1094DQDP.00
  <01ISLNBFKIDS94DUJ8@sesta.com>

MTA ログの例: リモート側のメッセージ送信試行が拒否される場合

この例では、MTA がリモート側のメッセージ送信の試行を拒否した場合のログエントリを示します。この例では、有効になっている LOG_* オプションがないと仮定されているため、基本的なフィールドだけがエントリにログ記録されています。LOG_CONNECTION オプションを有効にすると、J エントリなどにその他の情報フィールドが追加されます。これは、ORIG_SEND_ACCESS マッピングを使って SMTP リレーブロッキング (「SMTP リレーブロッキングを設定する」を参照) が設定されている MTA の場合の例です。

ORIG_SEND_ACCESS

! ...多数のエントリを省略...
!
   tcp_local|*|tcp_local|*   $NRelaying$ not$ permitted

alan@very.bogus.com は内部アドレスではありません。したがって、リモートユーザー harold@varrius.com が MTA システムを介してリモートユーザー alan@very.bogus.com にリレーしようとしても、拒否されます。


例 21–6 MTA ログ: リモート側のメッセージ送信試行が拒否される場合


28-May-1998 12:02:23 tcp_local            J 0               (1)
 harold@varrius.com rfc822; alan@very.bogus.com             (2)
 550 5.7.1 Relaying not permitted: alan@very.bogus.com      (3)
  1. このログは、MTA がリモート側のメッセージ送信の試行を拒否した日付と時刻を示しています。拒否は J レコードで示されています。MTA チャネルが拒否されるメッセージを送信しようとすると、例 21–4例 21–5 で示されているように R レコードで示されます。


    注 –

    ログに書き込まれた最後の J レコードは、特定のセッションの最後のレコードであることを示します。また、Messaging Server の現在のバージョンは J レコードの数を制限しません。


  2. 試行されたエンベロープ From: および To: アドレスが示されています。この場合、利用できる元のエンベロープ To: 情報がなかったため、フィールドは空です。

  3. このエントリには、MTA がリモート (試行した差出人) 側に発行した SMTP エラーメッセージが含まれています。


MTA ログの例: 配信試行が複数回行われた場合

ここでは、メッセージを最初の試行で配信できなかったために、MTA が何度もメッセージを送信しようとする場合のログエントリの例を示します。この例では、LOG_FILENAME=1LOG_MESSAGE_ID=1 というオプションが設定されていると仮定しています。


例 21–7 MTA ログ: 配信試行が複数回行われた場合


15-Jan-1998 10:31:05.18 tcp_internal   tcp_local   E 3          (1)
 adam@hosta.sesta.com rfc822;user@some.org user@some.org
 imta/queue/tcp_local/ZZ01IS3D2ZP7FQ9UN54R.00 
 <01IRUD7SVA3Q9UN2D4@sesta.com>
 
15-Jan-1998 10:31:10.37 tcp_local                  Q 3          (2)
 adam@hosta.sesta.com rfc822;user@some.org user@some.org
 imta/queue/tcp_local/ZZ01IS3D2ZP7FQ9UN54R.00                   (3)
 <01IRUD7SVA3Q9UN2D4@sesta.com>
 TCP active open: Failed connect()    Error: no route to host   (4)
 
     ...several hours worth of entries...

15-Jan-1998 12:45:39.48 tcp_local                  Q 3          (5)
  adam@hosta.sesta.com rfc822;user@some.org user@some.org
  imta/queue/tcp_local/ZY01IS3D2ZP7FQ9UN54R.00                  (6)
  <01IRUD7SVA3Q9UN2D4@sesta.com>
  TCP active open: Failed connect()    Error: no route to host
 
  ...several hours worth of entries...

 15-Jan-1998 16:45:24.72 tcp_local                  Q 3
  adam@hosta.sesta.com rfc822;user@some.org user@some.org
  imta/queue/tcp_local/ZX01IS67NY4RRK9UN7GP.00                  (7)
                   <01IRUD7SVA3Q9UN2D4@sesta.com>
  TCP active open: Failed connect() Error: connection refused   (8)

  ...several hours worth of entries...

 15-Jan-1998 20:45:51.55 tcp_local                  D 3         (9)
  adam@hosta.sesta.com rfc822;user@some.org user@some.org
  imta/queue/tcp_local/ZX01IS67NY4RRK9UN7GP.00
  <01IRUD7SVA3Q9UN2D4@sesta.com>
  dns;host.some.org (TCP|206.184.139.12|2788|192.1.1.1|25)
  (All set, fire away)
  smtp; 250 Ok
  1. メッセージは tcp_internal チャネルに入ります。これは、おそらく POP または IMAP クライアント、または SMTP リレーとして MTA を使用している組織内の別のホストから来たものです。MTA はこれを送信 tcp_local チャネルのキューに入れます。

  2. 最初の配信試行に失敗しています。これは Q エントリで示されています。

  3. これが最初の配信試行であることは、ZZ* ファイル名からわかります。

  4. この配信試行は、TCP/IP パッケージがリモート側への経路を見つけられなかったために失敗しました。例 21–4 とは異なり、DNS は宛先ドメイン名 some.org を否定していません。「no route to host」」というエラーは、送信側と受信側の間にネットワーク上の問題があることを示しています。

  5. MTA の定期的なジョブの次の実行時に、配信が再試行され、再び失敗しています。

  6. ここでファイル名が ZY* になり、2 回目の試行であることを示しています。

  7. ファイル名が ZX* になり、3 回目の失敗した試行であることを示しています。

  8. 定期的なジョブが配信を再試行し、再び失敗しています。ただし、ここでは TCP/IP パッケージがリモートの SMTP サーバーに接続できなかったことが示されているのではなく、リモートの SMTP サーバーが接続を受け入れないことを示しています。リモート側のネットワーク上の問題は解決されても、SMTP サーバーをまだ起動していない、またはその SMTP サーバーのメッセージ処理が追いつかないなどの理由で、MTA が接続しようとした時点で接続が受け入れられなかったことが考えられます。

  9. メッセージがキューから取り出されています。


MTA ログ: 変換チャネルを通過する着信 SMTP メッセージ

ここでは、メッセージが変換チャネルを通過する場合の例を示します。このサイトには、以下のような CONVERSIONS マッピングテーブルがあると仮定しています。

CONVERSIONS
  IN-CHAN=tcp_local;OUT-CHAN=l;CONVERT   Yes

この例では、LOG_FILENAME=1LOG_MESSAGE_ID=1 というオプションが設定されていると仮定しています。


例 21–8 MTA ログ: 変換チャネルを通過する着信 SMTP メッセージ


04-Feb-1998 00:06:26.72 tcp_local    conversion   E 9      (1)
  amy@siroe.edu rfc822;bert@sesta.com bert@sesta.com
  imta/queue/conversion/ZZ01IT5UAMZ4QW98518O.00
  <01IT5UALL14498518O@siroe.edu>
 
 04-Feb-1998 00:06:29.06 conversion   l            E 9     (2)
                   amy@siroe.edu rfc822;bert@sesta.com bert
  imta/queue/l/ZZ01IT5UAOXLDW98509E.00  <01IT5STUMUFO984Z8L@siroe.edu>
 
04-Feb-1998 00:06:29.31 conversion                D 9      (3)
 amy@siroe.edu rfc822;bert@sesta.com bert
 imta/queue/conversion/ZZ01IT5UAMZ4QW98518O.00
 <01IT5UALL14498518O@siroe.edu>
 
 04-Feb-1998 00:06:32.62 l                         D 9     (4)
  amy@siroe.edu rfc822;bert@siroe.com bert
  imta/queue/l/ZZ01IT5UAOXLDW98509E.00
  <01IT5STUMUFO984Z8L@siroe.edu>

               
  1. 外部ユーザー amy@siroe.edu からのメッセージがチャネル l の受取人 bert@sesta.com に届きました。しかし、CONVERSIONS マッピングエントリにより、このメッセージは直接チャネル l には送られず、最初に変換チャネルのキューに入れられます。

  2. 変換チャネルが実行され、メッセージがチャネル l のキューに入れられます。

  3. 変換チャネルはメッセージをキューから取り出す (古いメッセージファイルを削除する) ことができます。

  4. 最後に、チャネル l のキューからメッセージが取り出され (配信され) ています。


MTA ログの例: 送信接続ログ

この例は、LOG_CONNECTION=3 によって接続ログが有効になっているときの送信メッセージのログ出力を示します。この例では、LOG_PROCESS=1LOG_MESSAGE_ID=1、および LOG_FILENAME=1 も設定されていると仮定されています。この例は、ユーザー adam@sesta.com が 3 人の受取人 (bobby@hosta.sesta.comcarl@hosta.sesta.com、および dave@hostb.sesta.com) に同じメッセージ (各メッセージコピーのメッセージ ID は同じ) を送信している場合を示しています。この例では、メッセージが (同様のチャネルが大抵そうであるように) single_sys チャネルキーワードで示された tcp_local チャネルから送信されていると仮定しています。したがって、(1)、(2)、(3) で示されているように、それぞれの受取人に対して、別々のメッセージファイルが別々のホスト名のディスク上に作成されます。bobby@hosta.sesta.comcarl@hosta.sesta.com の受取人は同じメッセージファイルに保存されますが、dave@hostb.sesta.com の受取人は別のメッセージファイルに保存されます。


例 21–9 MTA ログ: 送信接続ログ


19-Feb-1998 10:52:05.41 1e488.0 l            tcp_local    E 1
 adam@sesta.com rfc822;bobby@hosta.sesta.com bobby@hosta.sesta.com
 imta/queue/tcp_local/ZZ01ITRF7BO388000FCN.00                    (1)
  <01ITRF7BDHS6000FCN@SESTA.COM>

19-Feb-1998 10:52:05.41 1e488.0 l            tcp_local    E 1
 adam@sesta.com rfc822;carl@hosta.sesta.com carl@hosta.sesta.com
 imta/queue/tcp_local/ZZ01ITRF7BO388000FCN.00                    (2)
   <01ITRF7BDHS6000FCN@SESTA.COM>

19-Feb-1998 10:52:05.74 1e488.1 l            tcp_local    E 1
 adam@sesta.com rfc822;dave@hostb.sesta.com dave@hostb.sesta.com
 imta/queue/tcp_local/ZZ01ITRF7C11FU000FCN.00                    (3)
   <01ITRF7BDHS6000FCN@SESTA.COM>

19-Feb-1998 10:52:10.79 1f625.2.0 tcp_local    -            O    (4)
 TCP|206.184.139.12|5900|206.184.139.66|25
 SMTP/hostb.sesta.com/mailhub.sesta.com                          (5)
 
19-Feb-1998 10:52:10.87 1f625.3.0 tcp_local    -            O    (6)
 TCP|206.184.139.12|5901|206.184.139.70|25
 SMTP/hosta.sesta.com/hosta.sesta.com                            (7)

19-Feb-1998 10:52:12.28 1f625.3.1 tcp_local                  D 1
 adam@sesta.com rfc822;bobby@hosta.sesta.com bobby@hosta.sesta.com
 imta/queue/tcp_local/ZZ01ITRF7BO388000FCN.00
  <01ITRF7BDHS6000FCN@SESTA.COM>
 hosta.sesta.com dns;hosta.sesta.com                            (8)
 (TCP|206.184.139.12|5901|206.184.139.70|25)
 (hosta.sesta.com -- Server ESMTP [iMS V5.0 #8790])
 (TCP|206.184.139.12|5901|206.184.139.70|25)
 smtp;250 2.1.5 bobby@hosta.sesta.com and options OK.

19-Feb-1998 10:52:12.28 1f625.3.1 tcp_local                  D 1
 adam@sesta.com rfc822;carl@hosta.sesta.com carl@hosta.sesta.com
 imta/queue/tcp_local/ZZ01ITRF7BO388000FCN.00
  <01ITRF7BDHS6000FCN@SESTA.COM>
 hosta.sesta.com dns;hosta.sesta.com
 (TCP|206.184.139.12|5901|206.184.139.70|25)
 (hosta.sesta.com -- Server ESMTP [iMS V5.0 #8790])
 (TCP|206.184.139.12|5901|206.184.139.70|25)
 smtp;250 2.1.5 carl@hosta.sesta.com and options OK.

19-Feb-1998 10:52:12.40 1f625.3.2 tcp_local      -            C  (9)
 TCP|206.184.139.12|5901|206.184.139.70|25
 SMTP/hosta.sesta.com/hosta.sesta.com

19-Feb-1998 10:52:13.01 1f625.2.1 tcp_local                  D 1
 adam@sesta.com rfc822;dave@hostb.sesta.com dave@hostb.sesta.com
 imta/queue/tcp_local/ZZ01ITRF7C11FU000FCN.00
  <01ITRF7BDHS6000FCN@SESTA.COM>
 mailhub.sesta.com dns;mailhub.sesta.com
 (TCP|206.184.139.12|5900|206.184.139.66|25)
 (MAILHUB.SESTA.COM -- Server ESMTP [iMS V5.0 #8694])
 (TCP|206.184.139.12|5900|206.184.139.66|25)
 smtp;250 2.1.5 dave@hostb.sesta.com and options OK.

19-Feb-1998 10:52:13.05 1f625.2.2 tcp_local      -            C  (10)
                  
 TCP|206.184.139.12|5900|206.184.139.66|25
 SMTP/hostb.sesta.com/mailhub.sesta.com

               
  1. 1 人目の受取人へのメッセージがキューに入れられます。

  2. 次に、2 人目の受取人へのメッセージがキューに入れられます。

  3. 最後に、3 人目の受取人へのメッセージがキューに入れられます。

  4. LOG_CONNECTION=3 が設定されているため、MTA がこのエントリを書き込みます。マイナス記号 (-) は、このエントリが送信接続であることを示しています。O は、このエントリが接続開始に対応することを意味しています。この接続開始はスレッド 2 とスレッド 3 によって実行されていますが、これらの個別の接続開始に対するマルチスレッド TCP/IP チャネルに同じプロセスが使用されているため、プロセス ID は同じ (1f625) であることに注意してください。

  5. 2 つの異なるリモートシステムに接続するため、別々のスレッドにあるマルチスレッド SMTP クライアントがそれぞれの接続を開いています。最初の接続はこのエントリで、2 番目の接続は 7 に示されています。エントリのこの部分には、送信側と受信側の IP 番号とポート番号、および最初のホスト名と DNS 検索で見つかったホスト名の両方が示されています。SMTP/initial-host/dns-host には、最初のホスト名と、DNS MX レコード検索を実行したあとで使用されるホスト名が表示されています。mailhub.sesta.com は、hostb.sesta.com の MX サーバーであることがわかります。

  6. マルチスレッド SMTP クライアントが、別のスレッドで 2 番目のシステムとの接続を開いています (プロセスは同じ)。

  7. 2 つの異なるリモートシステムに接続するため、別々のスレッドにあるマルチスレッド SMTP クライアントがそれぞれの接続を開いています。2 番目の接続はこのエントリで、最初の接続は上記の 5 に示されています。エントリのこの部分には、送信側と受信側の IP 番号とポート番号、および最初のホスト名と DNS 検索で見つかったホスト名の両方が示されています。この例では、hosta.sesta.com というシステムがメールを直接受信することがわかります。

  8. この例に示されているように、特定の接続エントリのほか、LOG_CONNECTION=3 によって接続に関連する情報が標準のメッセージエントリに組み込まれます。

  9. LOG_CONNECTION=3 が設定されているため、MTA がこのエントリを書き込みます。メッセージ (この例では bobby と carl のメッセージ) がキューから取り出されたあと、接続が終了します。このエントリでは C で示されています。


MTA ログの例: 受信接続ログ

この例では、LOG_CONNECTION=3 によって接続ログが有効になっているときの着信 SMTP メッセージのログ出力を示します。


例 21–10 MTA ログ: 受信接続ログ


19-Feb-1998 17:02:08.70 tcp_local    +            O          (1)
 TCP|206.184.139.12|25|192.160.253.66|1244 SMTP              (2)

19-Feb-1998 17:02:26.65 tcp_local    l             E 1
 service@siroe.com rfc822;adam@sesta.com adam
 THOR.SIROE.COM (THOR.SIROE.COM [192.160.253.66])            (3)

 19-Feb-1998 17:02:27.05 tcp_local    +             C        (4)
                   TCP|206.184.139.12|25|192.160.253.66|1244 SMTP
 
19-Feb-1998 17:02:31.73 l                          D 1
  service@siroe.com rfc822;adam@sesta.com adam
  1. リモートシステムが接続を開きます。O は、このエントリが接続開始に対応したものであることを示しています。+ は、このエントリが着信接続であることを示しています。

  2. 接続の IP 番号とポートが示されています。このエントリでは、受信システム (ログファイルエントリを記録しているシステム) の IP アドレスは 206.184.139.12、ポート番号は 25、送信システムの IP アドレスは 192.160.253.66、ポートは 1244 です。

  3. このエントリは、着信 TCP/IP チャネル (tcp_local) からチャネル l の受取人に送られるメッセージがキューに入っていることを示しています。LOG_CONNECTION=3 が有効になっているため、デフォルト以外の情報も含まれています。特に、送信システムがその HELO または EHLO 行に示す名前、接続 IP 番号の DNS リバース検索で見つかった送信システムの名前、および送信システムの IP アドレスが、すべてログに記録されます。この動作に影響するチャネルキーワードについては、第 12 章「チャネル定義を設定する」を参照してください。

  4. 着信接続が閉じています。C は、このエントリが接続終了に対応したものであることを示しています。+ は、このエントリが着信接続であることを示しています。


ディスパッチャーのデバッグを有効にする

ディスパッチャーエラーとデバッグ出力 (有効になっている場合) は、MTA ログディレクトリ内の dispatcher.log ファイルに書き込まれます。ディスパッチャーの設定情報は、msg_svr_base/imta/dispatcher.cnf ファイルに指定されます。インストール時に作成されたデフォルトの設定ファイルをそのまま使用することができます。ただし、セキュリティーやパフォーマンスなどの理由でデフォルトの設定ファイルを変更する場合は、dispatcher.cnf ファイルを編集することができます。

表 21–3 ディスパッチャーデバッグビット

ビット 

 

16 進数値 

10 進数値 

使用目的 

 

x 00001 

サービスディスパッチャーのメインモジュールの基本的なデバッグ。 

x 00002 

サービスディスパッチャーのメインモジュールの特別なデバッグ。 

x 00004 

サービスディスパッチャー設定ファイルのログ処理。 

x 00008 

サービスディスパッチャーに関するその他の基本的なデバッグ。 

x 00010 

16 

サービスの基本的なデバッグ。 

x 00020 

32 

サービスの特別なデバッグ。 

x 00040 

64 

プロセスに関連するサービスのデバッグ。 

x 00080 

128 

使用されていません。 

x 00100 

256 

サービスディスパッチャーとプロセス通信の基本的なデバッグ。 

x 00200 

512 

サービスディスパッチャーとプロセス通信の特別なデバッグ。 

10 

x 00400 

1024 

パケットレベル通信のデバッグ。 

11 

x 00800 

2048 

使用されていません。 

12 

x 01000 

4096 

ワーカープロセスの基本的なデバッグ。 

13 

x 02000 

8192 

ワーカープロセスの特別なデバッグ。 

14 

x 04000 

16384 

その他のワーカープロセスのデバッグ (特に接続ハンドオフ)。 

15 

x 08000 

32768 

使用されていません。 

16 

x 10000 

65536 

サービスディスパッチャー I/O に対するワーカープロセスの基本的なデバッグ。 

17 

x 20000 

131072 

サービスディスパッチャー I/O に対するワーカープロセスの特別なデバッグ。 

20 

x 100000 

1048576 

統計の基本的なデバッグ。 

21 

x 200000 

2097152 

統計の特別なデバッグ。 

24 

x 1000000 

16777216 

PORT_ACCESS 拒否の dispatcher.log ファイルへのログ。 

Procedureディスパッチャーのエラーデバッグ出力を有効にする

手順
  1. dispatcher.cnf ファイルを編集します。

  2. DEBUG オプションを -1 に設定します。

    論理または環境変数の IMTA_DISPATCHER_DEBUG (UNIX) を設定することもできます。この変数は、32 ビットのデバッグマスクに 16 進数の FFFFFFFF の値を定義します。上の表には、各ビットの意味の説明があります。

Procedureディスパッチャーパラメータを設定する (Solaris)

ディスパッチャー設定ファイルで提供されるディスパッチャーサービスは、さまざまなシステムパラメータの必要要件に影響を与えます。システムのヒープサイズ (datasize) は、ディスパッチャーによるスレッドスタックの使用を考慮して十分なサイズに設定する必要があります。

手順
  1. ヒープサイズ (つまり、デフォルトの datasize) を表示するには、次のいずれかを使用します。

    csh コマンド:


    # limit
    

    ksh コマンド


    # ulimit -a
    

    Solaris ユーティリティー


    # sysdef
    
  2. 各ディスパッチャーサービスに対して、STACKSIZE*MAX_CONNS を計算し、それらの計算値を合計します。システムのヒープサイズは、この合計値の 2 倍以上でなければなりません。