MTA が起動に失敗すると、コマンド行に一般的なエラーメッセージが表示されます。この節では、共通の一般的なエラーメッセージの説明と診断を示します。
MTA 設定を診断するには、imsimta test -rewrite -debug ユーティリティーを使用して MTA のアドレス書き換えとチャネルマッピング処理を調べます。このユーティリティーを使用すれば、メッセージを実際に送信しなくても設定をチェックすることができます。詳細については、「MTA 設定をチェックする」を参照してください。
MTA サブコンポーネントは、この章では説明していないほかのエラーメッセージを発行することもあります。各サブコンポーネントの詳細については、『 Sun Java System Messaging Server Administration Reference』の MTA コマンド行ユーティリティーおよび設定の章と、第 5 章から第 10 章を参照してください。ここでは、次のタイプのエラーについて説明します。
mm_init でのエラーは、通常は MTA の設定の問題を示します。imsimta test -rewrite ユーティリティーを実行する場合は、これらのエラーが表示されます。imsimta cnbuild などのその他のユーティリティー、チャネル、サーバー、またはブラウザがこのようなエラーを返すこともあります。
よく発生する mm_init エラーには以下のものがあります。
エイリアスファイルのエントリの右側が適切にフォーマットされていません。
エイリアスファイルに含まれているファイルを開くことができません。
エイリアスファイルの 2 つのエントリで、左側が同じになっています。重複するものを見つけて削除する必要があります。error line #XXX というエラーメッセージを探します。XXX は行番号です。この行にある重複のエイリアスを修正することができます。
このエラーメッセージは、MTA の設定に 2 つのチャネル定義があり、両方に同じ正規ホスト名があることを示しています。
MTA 設定ファイル (imta.cnf) の書き換えルール (上部) に関係のない空白行があると、MTA は設定ファイルの残りの部分をチャネル定義と解釈します。ファイルの最初の行が空白でないことを確認してください。同じパターンを持つ書き換えルール (左側) が複数あると、MTA はそれらの書き換えルールを、一意でない正規のホスト名を含むチャネル定義と解釈します。正規のホスト名が重複しているチャネル定義がないかどうか、また、ファイル上部 (書き換えルールの部分) に不適切な空白行がないかどうか、MTA の設定をチェックしてください。
このメッセージは、2 つのマッピングテーブルに同じ名前が付いていて、これらの重複するマッピングテーブルのいずれかを削除する必要があることを示します。ただし、マッピングファイル内のフォーマットエラーによって、MTA が何かを間違ってマッピングテーブル名と解釈することもあります。たとえば、マッピングテーブルエントリが適切にインデントされていないと、MTA はエントリの左側が実際にマッピングテーブル名であるとみなします。マッピングファイルが一般の形式であることと、マッピングテーブル名をチェックしてください。
空白行はマッピングテーブル名を含む行の前と後ろに付ける必要があります。ただし、空白行をマッピングテーブルのエントリ間に入れないでください。
このエラーは、マッピングテーブル名が長すぎるので、短くする必要があることを示しています。マッピングファイル内のフォーマットエラーによって、MTA が何かを間違ってマッピングテーブル名と解釈することもあります。たとえば、マッピングテーブルエントリが適切にインデントされていないと、MTA はエントリの左側が実際にマッピングテーブル名であるとみなします。マッピングファイルとマッピングファイル名をチェックしてください。
このメッセージが表示された場合は、imsimta chbuild. コマンドを使用して、コンパイル済みの文字セットテーブルを再コンパイルして再インストールする必要があります。詳細は、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』の「imsimta chbuild」を参照してください。
通常、このエラーメッセージは、MTA 文字セットの内部テーブルのサイズを変更し、次のコマンドでコンパイル済み文字セットテーブルを再構築する必要があることを意味しています。
imsimta chbuild -noimage -maximum -option imsimta chbuild |
この変更を加える前に、ほかには何も再コンパイルまたは再起動する必要がないことを確認してください。imsimta chbuild の詳細については、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』の「imsimta chbuild」を参照してください。
このエラーは、ローカルホストエイリアスまたは固有名詞が長すぎることを示します (オプションで、チャネルブロックの 2 番目以降の名前の右側にある)。ただし、MTA 設定ファイル内でこのエラーより前に構文エラー (書き換えルールに関係のない空白行がある場合など) がある場合は、MTA が何かを間違ってチャネル定義と解釈することもあります。設定ファイルの指定されている行をチェックするだけでなく、その行より上にほかの構文エラーがないかどうかもチェックしてください。特に、このエラーが発生した行が書き換えルールを意図する行である場合は、その行より上に関係のない空白行がないかどうかを必ずチェックしてください。
エイリアスファイル内のエントリの右側 (変換値) がありません。
このエラーは、チャネル定義ブロックに必須の 2 番目の行 (正規のホスト名の行) がないことを示しています。チャネル定義ブロックの詳細については、『 Sun Java System Messaging Server Administration Reference』の MTA の設定およびコマンド行ユーティリティーの章と、第 12 章「チャネル定義を設定する」を参照してください。それぞれのチャネル定義ブロックの前と後ろには空白行が必要ですが、空白行をチャネル定義のチャネル名と正規のホスト名の行の間に入れることはできません。また、空白行は MTA 設定ファイルの書き換えルール部分には入れることはできません。
チャネルの正規のホスト名 (チャネル定義ブロックの 2 行目) は、長さが 128 オクテットに制限されています。チャネル上で長めの正規ホスト名を使用しようとしている場合は、それをプレースホルダ名まで短くしてから、書き換えルールを使用してその長めの名前がその短い正規ホスト名に一致するようにします。このような状況は、l (ローカル) チャネルホスト名を使用しているときに起こることがあります。次に例を示します。
Original l Channel: !ローカル /var/mail ストアへの配信チャネル l subdirs 20 viaaliasrequired maxjobs 7 pool LOCAL_POOL walleroo.pocofronitas.thisnameismuchtoolongandreallymakesnosensebutitisan example.monkey.gorilla.orangutan.antidisestablismentarianism.newt.salaman der.lizard.gecko.komododragon.com Create Place Holder: !ローカル /var/mail ストアへの配信チャネル l subdirs 20 viaaliasrequired maxjobs 7 pool LOCAL_POOL newt Create Rewrite Rule: newt.salamander.lizard.gecko.komododragon.com $U%$D@newt |
l (ローカル) チャネルを使用しているときは、REVERSE マッピングテーブルを使用する必要があります。使用法と構文の詳細については、『Sun Java System Messaging Server Administration Reference』の MTA 設定の章を参照してください。
MTA 設定ファイル内でこのエラーより前に構文エラー (書き換えルールに関係のない空白行があった場合など) がある場合は、MTA が何かを間違ってチャネル定義と解釈することもあります。このため、書き換えルールを意図していたとしても、正規のホスト名と解釈されてしまうことがあります。設定ファイルの指定されている行をチェックするだけでなく、その行より上にほかの構文エラーがないかどうかもチェックしてください。特に、このエラーが発生した行が書き換えルールを意図する行である場合は、その行より上に関係のない空白行がないかどうかを必ずチェックしてください。
imsimta cnbuild ユーティリティーの機能の 1 つとして、MTA の設定情報を、すばやく読み込むことができるイメージにコンパイルする機能があります。コンパイル済みフォーマットは厳密に定義されており、多くの場合、異なるバージョンの MTA 間では実質的に異なっています。小さな変更はパッチリリースとして発生することもあります。
このような変更が発生すると、互換性のないフォーマットを検出するために、内部バージョンフィールドも変更されます。互換性のないフォーマットを検出すると、MTA コンポーネントは上記のエラーで停止します。この問題の解決策は、imsimta cnbuild コマンドを使って新しいコンパイル済み設定を生成することです。
また、imsimta restart コマンドを使用して常駐 MTA サーバープロセスを再起動することも良い方法です。これによって、常駐 MTA サーバープロセスは更新された設定情報を取得することができます。
適切な動作を保証するために、メッセージングシステム上に十分なスワップ空間を設定することが重要です。必要なスワップ空間の量は設定によって異なります。調整の際に一般的に推奨されるのは、スワップ空間の量を主記憶容量の少なくとも 3 倍にすることです。
次のようなエラーメッセージは、スワップ空間が不足していることを示しています。
jbc_channels: chan_execute [1]: fork failed: Not enough space
このエラーはジョブコントローラのログファイルで見られることがあります。その他のスワップ空間のエラーは設定によって異なります。
次のコマンドを使用して、スワップ空間の空き容量と使用容量を確認します。
Solaris システム: swap -s (MTA プロセスがビジー状態のとき)、ps -elf、または tail /var/adm/messages
HP-UX システム: swapinfo または tail /var/adm/syslog/syslog.log
メッセージを送信するために、MTA は設定ファイルを読み取って、MTA メッセージキューディレクトリにメッセージファイルを作成します。設定ファイルは、MTA または MTA の SDK に対して書かれたプログラムが読み取ることのできるものでなければなりません。適切な権限はこれらのファイルのインストール中に割り当てられます。設定ファイルを作成する MTA ユーティリティーとプロシージャーも、権限を割り当てます。ファイルがシステムマネージャー、特権を持つほかのユーザー、またはサイト固有のプロシージャーによって保護されている場合、MTA は設定情報を読み取ることができない場合があります。その結果、「ファイルオープン」エラーや予測不能な動作が発生します。設定ファイルの読み取りに関する問題が発生したときは、imsimta test -rewrite ユーティリティーが追加情報をレポートします。詳細については、『Sun Java System Messaging Server 6 2005Q4 Administration Reference』の「imsimta test」を参照してください。
MTA が、権限を持つアカウントから機能していて、権限のないアカウントからは機能していないように見える場合は、MTA テーブルディレクトリのファイルアクセス権が問題の原因と思われます。設定ファイルとそのディレクトリのアクセス権をチェックしてください。詳細については、「危険なファイルの所有権をチェックする」を参照してください。
「ファイル作成」エラーは、通常、MTA メッセージキューディレクトリにメッセージファイルを作成する際に問題が発生したことを示しています。ファイル作成に関する問題の診断については、「メッセージキューディレクトリをチェックする」を参照してください。
このエラーは、ブラウザで MTA にアドレスを指定したときに見られることがあります。また、このエラーは、据え置かれて、エラー返送メールメッセージの一部として返送されることがあります。どちらの場合もこのエラーメッセージは、MTA が指定したホストにメールを配信できないことを示しています。メールが指定したホストに送信されていない原因を確認するには、以下のトラブルシューティング手順に従います。
該当するアドレスにスペルミスがないかどうか、コピーミスがないかどうか、存在していないホストまたはドメインの名前を使用していないかどうかを確認します。
imsimta test -rewrite ユーティリティーを使って該当するアドレスを実行します。このユーティリティーを使用してもアドレスで「不正なホスト/ドメイン」エラーが返される場合は、MTA の imta.cnf ファイルと関連ファイルにアドレスを処理するルールがありません。MTA が正しく設定されているかどうか、設定の際のすべての質問に適切に回答したかどうか、設定情報が最新のものになっているかどうかを確認してください。
imsimta test -rewrite によってアドレスでエラーが発生しない場合、MTA はアドレスの処理方法を決定できるが、ネットワーク転送はそれを受け入れません。追加の詳細については、配信試行の際に作成された該当するログファイルを調べることができます。一時的なネットワークのルーティングエラーまたはネームサービスエラーが発生したことにより、エラーメッセージが返されることはありません。ただし、ドメインネームサーバーの設定が大幅に間違っていると、このようなエラーが発生する可能性があります。
インターネット上の場合は、MX レコード検索をサポートするように TCP/IP チャネルが正しく設定されているかどうかチェックします。多くのドメインアドレスはインターネットに直接アクセスすることはできず、メールシステムが正しく MX エントリを解決する必要があります。インターネット上の場合、および TCP/IP が MX レコードをサポートするように設定されている場合は、MX サポートを有効にするように MTA を設定する必要があります。詳細は、「TCP/IP 接続と DNS 検索のサポート」を参照してください。TCP/IP パッケージが MX レコード検索をサポートするように設定されていない場合は、MX 専用ドメインにアクセスすることはできません。
os_smtp_open、os_smtp_read、os_smtp_write などの os_smtp_* エラーは、必ずしも MTA エラーではありません。これらのエラーは、MTA がネットワーク層で発生した問題をレポートするときに生成されます。たとえば、os_smtp_open エラーは、リモート側へのネットワーク接続を開くことができなかったことを意味します。MTA は、アドレスエラーやチャネル設定エラーのために無効なシステムに接続するよう設定されていることがあります。一般的に os_smtp_* エラーは、DNS またはネットワーク接続の問題が原因です (特に、以前に動作していたチャネルやアドレスの場合)。os_smtp_read または os_smtp_write エラーは、一般的に、接続がリモート側で強制終了されたか、ネットワーク上の問題によるものであることを示しています。
多くの場合、ネットワークおよび DNS の問題は実際には一時的です。ときどき発生する os_smtp_* エラーは、通常は気にしなくても大丈夫です。ただし、これらのエラーが頻繁に表示される場合は、根本的なネットワーク上の問題がある可能性があります。
特定の os_smtp_* エラーに関する詳細情報を入手するには、該当するチャネル上でデバッグを有効にします。試行された SMTP ダイアログの詳細を示す、デバッグチャネルのログファイルを調べます。特に、ネットワークの問題が SMTP ダイアログのどこのタイミングで発生したかを確認します。このタイミングは、ネットワークまたはリモート側の問題の種類を示していることがあります。場合によっては、ネットワークレベルのデバッグ (たとえば、TCP/IP パケットトレース) を実行して、何を送信または受信したかを確認することもできます。