Sun Java System Messaging Server 6.3 管理ガイド

20.14.4 一般的な問題と解決策

この節では、次のようなメッセージストアの一般的な問題と解決策の一覧を示します。

20.14.4.1 Linux - Messaging Server パッチ 120230-08: プロセスあたりのセッション数超過のために IMAP サーバー、POP サーバー、および HTTP サーバーが起動しない

このパッチのインストール後、Messaging Server を起動しようとすると、IMAP サーバー、POP サーバー、および HTTP サーバーが起動せず、次の例のようなエラーログが送信されることがあります。

http server - log:
[29/May/2006:17:44:37 +051800] usg197 httpd[6751]: General Critical: Not enough file 
descriptors to support 6000 sessions per process; Recommend ulimit -n 12851 or 87 
sessions per process.

pop server - log:
[29/May/2006:17:44:37 +051800] usg197 popd[6749]: General Critical: Not enough file 
descriptors to support 600 sessions per process; Recommend ulimit -n 2651 or 58 
sessions per process.

Once these values setting in /opt/sun/messaging/sbin/configutil then imap server 
failed to start

imap server - log: 
[29/May/2006:17:44:37 +051800] usg197 imapd[6747]: General Critical: Not enough 
file descriptors to support 4000 sessions per process; Recommend ulimit -n 12851 
or 58 sessions per process.

3 つのサーバーセッションに対応する適切なファイル記述子の数を設定してください。追加のファイル記述子は、/etc/sysctl.conf に次のような行を追加し、sysctl -p を使用してそのファイルを再度読み込むことによって使用可能になります。

fs.file-max = 65536

また、/etc/security/limits.conf にも次のような行を追加してください。

*   soft  nofile  65536  
*   hard  nofile  65536

20.14.4.2 Messenger Express または Communications Express がメールページを読み込まない

ユーザーが Messenger Express ページまたは Communications Express メールページを読み込めない場合は、圧縮後にデータが破損している可能性があります。これは、古いプロキシサーバーがシステムに配備されている場合に発生することがあります。この問題を解決するには、local.service.http.gzip.static および local.service.http.gzip.dynamic を 0 に設定して、データ圧縮を無効にしてください。これで問題が解決したら、プロキシサーバーを更新することができます。

20.14.4.3 ワイルドカードパターンを使用したコマンドが機能しない

UNIX シェルには、ワイルドカードパターンを引用符で囲む必要があるものとその必要のないものがあります。たとえば、C シェルはワイルドカード (*、?) を含む引数をファイルとして展開しようとするため、一致するものがない場合は失敗します。これらのパターンマッチング引数は、mboxutil のようなコマンドに渡すためには引用符で囲む必要があります。

次に例を示します。

mboxutil -l -p user/usr44*

これは Bourne シェルで機能しますが、tsch や C シェルでは失敗します。これらのシェルには次のコマンドが必要です。

mboxutil -l -p "user/usr44*"

ワイルドカードパターンを使用したコマンドが機能しない場合は、そのシェルではワイルドカードを引用符で囲む必要があるかどうかを確認してください。

20.14.4.4 不明または無効なパーティション

ユーザーのメールボックスが作成したばかりの新しいパーティションに移動され、Messaging Server が更新または再起動されていない場合、Messenger Express で「パーティションが不明または無効です」というメッセージが表示されることがあります。この問題は新しいパーティションでのみ発生します。この新しいパーティションにユーザーメールボックスを新しく追加する場合、Messaging Server の更新または再起動を行う必要はありません。

20.14.4.5 ユーザーメールボックスディレクトリに関する問題

ユーザーメールボックスに関する問題が発生するのは、メッセージストアの損傷が少数のユーザーに限られていて、システム全体に対する損傷がないときです。ユーザーメールボックスのディレクトリに関する問題を識別、分析、および解決する際は、次のガイドラインを参考にしてください。

ログファイル、エラーメッセージ、またはユーザーが見た異常な動作を確認します。
デバッグ情報と履歴を保存しておくには、store_root/mboxlist/ ユーザーディレクトリ全体を、メッセージストア外部の別の場所にコピーします。
問題の原因になっている可能性のあるユーザーフォルダを見つけるには、reconstruct -r -n コマンドを実行します。reconstruct を使用しても問題のあるフォルダが見つからない場合は、該当のフォルダが folder.db 内にない可能性があります。

reconstruct -r -n コマンドを使用してもフォルダが見つからない場合は、hashdir コマンドを使用して場所を確認します。hashdir の詳細については、「20.11.2.3 hashdir ユーティリティー」および、『Sun Java System Messaging Server 6.3 Administration Reference』の Messaging Server コマンド行ユーティリティーの章の hashdir ユーティリティーを参照してください。
ファイルが見つかったら、ファイルを調べ、権限をチェックし、適切なファイルのサイズを確認します。
reconstruct -r (-n オプションは付けない) を使用して、メールボックスを再構築します。
reconstruct で問題が検出されない場合は、reconstruct -r -f コマンドを使用して、メールフォルダを強制的に再構築することができます。
フォルダが mboxlist ディレクトリ (store_root/mboxlist) 内にはなく、partition ディレクトリ (store_root/partition) にある場合は、全体的な矛盾がある可能性があります。この場合は、reconstruct -m コマンドを実行する必要があります。
上記の手順が機能しない場合は、store.idx ファイルを削除してから、再度 reconstruct コマンドを実行してください。

注意 –
問題のあるファイルが reconstruct では見つからないファイルであることがわかっている場合は、store.idx ファイルだけを削除してください。
原因が問題を起こすメッセージに限られている場合は、メッセージファイルをメッセージストアの外側の別の場所にコピーしてから、mailbox/ ディレクトリ上で reconstruct -r コマンドを実行する必要があります。
フォルダがディスク (store_root/partition/ ディレクトリ) 上にあっても、明らかにデータベース (store_root/mboxlist/ ディレクトリ) 内にはないことがわかった場合は、reconstruct -m コマンドを実行してメッセージストアの整合性をチェックします。

reconstruct コマンドの詳細については、「20.14.3 メールボックスとメールボックスデータベースの修復」を参照してください。

20.14.4.6 store デーモンが起動しない

stored が起動せずに次のエラーメッセージが表示される場合があります。

# msg-svr-base/sbin/start-msg

msg-svr-base: Starting STORE daemon ...Fatal error: Cannot
find group in name service

上記のメッセージは、local.servergid に設定された UNIX グループが見つからないことを示しています。Stored などは、gid をグループに設定する必要があります。local.servergid によって定義されたグループが誤って削除されることがあります。この場合は、削除されたグループを作成し、mailsrv をグループに追加し、instance_root の所有権とそのファイルを mailsrv とグループに変更します。

20.14.4.7 メールボックスのオーバーフローによりユーザーメールが配信されない

メッセージストアには store.idx ファイルに関して 2G バイトという強い制限があります。これは、1 メールボックス (フォルダ) あたりおよそ 100 万メッセージに相当します。store.idx ファイルが 2G バイトを超えそうなレベルまでメールボックスが大きくなると、ユーザーは新しい電子メールを受信できなくなります。また、imapd、popd、mshttpd など、そのメールボックスを処理するほかのプロセスのパフォーマンスも低下する可能性があります。

この問題が発生すると、mail.log_current に次のようなエラーが出力されます。

05-Oct-2005 16:09:09.63 ims-ms Q 7 ...System I/O error.Administrator, check server log for details.System I/O error.

また、MTA のログファイルにも次のようなエラーが出力されます。

[05/Oct/2005:16:09:09 +0900] jmail ims_master[20745]:Store Error:Unable to append cache for user/admin:File too large

この問題を最終的に特定するには、ユーザーのメッセージストアディレクトリ内の該当するファイルを確認するか、または imta ログファイルで詳細なメッセージを確認します。

当面の措置としては、ファイルのサイズを減らします。一部のメールを削除するか、別のメールボックスに移動します。また、mboxutil -r を使用して該当するフォルダの名前を別のものに変更したり、mboxutil -d を使用してフォルダを削除したりすることもできます (「20.11.2.1 mboxutil ユーティリティー」を参照)。

長期的には、ユーザーに対するメールボックスのサイズ制限の周知、存続期間決定ポリシー (「20.9 自動メッセージ削除 (有効期限および消去) 機能を設定する」を参照) および制限容量ポリシー (「20.8 メッセージストアの制限容量について」を参照) の実装、local.store.maxmessages を設定することによるメールボックス制限値の設定 (『Sun Java System Messaging Server 6.3 Administration Reference』の「configutil Parameters」を参照)、アーカイブシステムの設定、またはメールボックスのサイズを抑制するためのなんらかの措置を行う必要があります。