この節では、障害に備えてメッセージストアを保守する際のガイドラインについて説明します。また、メッセージストアが壊れたり、予期せずシャットダウンされた場合に使用する、その他のメッセージストアの回復手順についても説明します。メッセージストア回復の追加手順に関する節は、「20.14.3 メールボックスとメールボックスデータベースの修復」の続きになります。
この節を読む前に、この章のこれまでの部分と、『Sun Java System Messaging Server Administration Reference』のコマンド行ユーティリティーおよび configutil に関する章を再度読まれますよう、強くお勧めします。この節では、次の項目について説明します。
ここでは、メッセージストアの監視の標準的な手順の概要を説明します。ここで説明する手順は、メッセージストアの全般的なチェック、テスト、および標準的な保守を行う場合に役立つものです。
その他の情報については、「27.7 メッセージストアを監視する」を参照してください。
メッセージストアには、十分な追加のディスク容量とハードウェアリソースが必要です。メッセージストアがディスク容量とハードウェア容量の上限に近づくと、メッセージストアに問題が発生することがあります。
ディスクの空き容量の不足は、メールサーバーで発生する問題や故障のうち、特に頻繁におきる原因の 1 つです。メッセージストアへ書き込むとき、そのための容量が不足していると、メールサーバーにエラーが発生します。さらに、利用可能なディスク容量が一定のしきい値より少なくなると、メッセージ配信やログ記録などに関連する多数の問題が発生します。stored プロセスのクリーンアップ機能が失敗し、削除されたメッセージがメッセージストアから消去されていないと、ディスク容量が急激に不足することがあります。
ディスク容量の監視の詳細については、「20.11.5 ディスク容量を監視する」および 「27.7 メッセージストアを監視する」を参照してください。
ログファイルをチェックして、メッセージストアプロセスが設定どおりに実行されていることを確認します。Messaging Server は、サポートしている主なプロトコルまたはサービス (SMTP、IMAP、POP、および HTTP) ごとに一連のログファイルを作成します。ログファイルは、msg-svr-base/log/ ディレクトリで表示できます。ログファイルは定期的に監視する必要があります。
ログ記録はサーバーパフォーマンスに影響することがあります。より詳細なログ記録を指定するほど、一定期間にログファイルが多くのディスク容量を占有することになります。効果的に定義する必要がありますが、現実的なログローテーション、有効期間、サーバーのバックアップポリシーなどを考慮する必要があります。サーバーのログポリシーの定義の詳細は、第 25 章「ログの管理」を参照してください。
Messaging Server では、テレメトリと呼ばれる機能が提供されており、ユーザーの IMAP、POP、または HTTP のセッション全体をファイルに取得できます。この機能は、クライアント問題をデバッグするのに便利です。たとえば、メッセージアクセスクライアントが期待どおりに機能しないとユーザーが訴えた場合、この機能を使用してアクセスクライアントと Messaging Server 間の対話を記録することができます。
POP セッションの記録をとるには、次のディレクトリを作成します。
msg-svr-base/data/telemetry/pop_or_imap_or_http/userid
POP セッションの記録をとるには、次のディレクトリを作成します。
msg-svr-base/data/telemetry/pop/ userid
IMAP セッションの記録をとるには、次のディレクトリを作成します。
msg-svr-base/data/telemetry/imap/ userid
Webmail セッションの記録をとるには、次のディレクトリを作成します。
msg-svr-base/data/telemetry/http/ userid
このディレクトリは、Messaging Server のユーザー ID によって所有され、書き込み可能である必要があります。
Messaging Server によって、セッションにつき 1 ファイルがそのディレクトリに作成されます。出力例を次に示します。
LOGIN redb 2003/11/26 13:03:21 >0.017>1 OK User logged in <0.047<2 XSERVERINFO MANAGEACCOUNTURL MANAGELISTSURL MANAGEFILTERSURL >0.003>* XSERVERINFO MANAGEACCOUNTURL {67} http://redb@cuisine.blue.planet.com:800/bin/user/admin/bin/enduser MANAGELISTSURL NIL MANAGEFILTERSURL NIL 2 OK Completed <0.046<3 select "INBOX" >0.236>* FLAGS (\Answered flagged draft deleted \Seen $MDNSent Junk) * OK [PERMANENTFLAGS (\Answered flag draft deleted \Seen $MDNSent Junk \*)] * 1538 EXISTS * 0 RECENT * OK [UNSEEN 23] * OK [UIDVALIDITY 1046219200] * OK [UIDNEXT 1968] 3 OK [READ-WRITE] Completed <0.045<4 UID fetch 1:* (FLAGS) >0.117>* 1 FETCH (FLAGS (\Seen) UID 330) * 2 FETCH (FLAGS (\Seen) UID 331) * 3 FETCH (FLAGS (\Seen) UID 332) * 4 FETCH (FLAGS (\Seen) UID 333) * 5 FETCH (FLAGS (\Seen) UID 334) <etc> |
stored 機能は、存続期間決定ポリシーを実行したり、ディスクに保存されているメッセージを消去して、メッセージデータベースのデッドロック操作やトランザクション操作などの、さまざまな重要なタスクを実行します。stored が実行を停止すると、最終的には Messaging Server に問題が発生します。start-msg が実行されているときに stored が起動していないと、ほかのプロセスも起動しません。
stored プロセスが実行中かどうかをチェックします。stored -t -v を実行します。
store_root/mboxlist 内に作成されたログファイルをチェックします。
デフォルトログファイルの msg-svr-base/log/default/default 内の stored メッセージをチェックします。
stored プロセスによって次の機能のいずれかが試行された場合は、必ず次のファイル (msg-svr-base/config/ ディレクトリ内) のタイムスタンプが更新されることを確認します。
stored 操作 |
機能 |
---|---|
stored.ckp |
データベースのチェックポイントが開始されたときに押されます。約 1 分ごとにスタンプが付けられます。 |
stored.lcu |
データベースログのクリーンアップごとに押されます。約 5 分ごとにタイムスタンプが付けられます。 |
stored.per |
ユーザー単位のデータベース書き込み時に押されます。タイムスタンプは 1 時間ごとに付けられます。 |
stored プロセスの詳細については、『Sun Java System Messaging Server 6.3 Administration Reference』の 「20.11.6 stored デーモン」の章を参照してください。
stored 機能の監視の詳細については、「27.7 メッセージストアを監視する」を参照してください。
データベースログファイルは、sleepycat トランザクションのチェックポイントログファイル (store_root/mboxlist ディレクトリ内) を指します。ログファイルが蓄積されると、データベースのチェックポイント設定は行われません。通常は、単一の期間内に、2 つまたは 3 つのデータベースログファイルがあります。ログファイルがそれ以上ある場合は、問題がある可能性があります。
ユーザーフォルダをチェックする場合は、次のコマンドを実行します。reconstruct -r -n (すべてのメールボックス、修復なし)。これにより、ユーザーフォルダおよびレポートのエラーを確認します。reconstruct コマンドの詳細については、「20.14.3 メールボックスとメールボックスデータベースの修復」を参照してください。
コアファイルは、プロセスが予期せず終了したときにのみ存在します。コアファイルを確認することは、メッセージストアに問題がありそうなときは特に重要です。Solaris の場合は、coreadm を使用して core ファイルの場所を設定します。
メッセージストアのデータはメッセージ、インデックスデータ、およびメッセージストアデータベースで構成されています。このデータは堅固ですが、ごくまれにメッセージストアのデータに関する問題がシステムに存在することがあります。このような問題はデフォルトのログファイルに示され、ほとんどの場合は透過的に修正されます。ただし、reconstruct ユーティリティーを実行する必要があることを示すエラーメッセージがログファイルに表示される場合がまれにあります。また、最終手段として、メッセージは 「20.12 メッセージストアのバックアップと復元を行う」で説明されているバックアップと復元のプロセスによって保護されます。この節では、stored の自動起動および回復プロセスについて説明します。
メッセージストアでは、以前は管理者の職責であった多くの回復処理が自動化されています。これらの処理はメッセージストアデーモンの stored によって起動時に実行され、必要に応じてデータベーススナップショットおよび自動高速復元が含まれます。stored によってメッセージストアのデータベースが徹底的にチェックされ、問題が検出された場合は自動的に修復されます。
また、stored は、デフォルトのログにステータスメッセージを出力することで、データベースのステータスの総合的な分析を提供し、メッセージストアに行われた修復およびメッセージストアを回復するために行われた自動試行について報告します。
stored デーモンは、ほかのメッセージストアプロセスが起動する前に起動します。このデーモンによってメッセージストアデータベースは初期化され、必要に応じて回復処理が行われます。メッセージストアデータベースは、フォルダ、容量制限、購読、およびメッセージフラグの情報を保持します。データベースはログ用とトランザクション用であるので、回復はすでに組み込まれています。また、一部のデータベース情報は、各フォルダのインデックス領域に予備でコピーされています。
データベースは非常に堅固ですが、まれに壊れたとしても、ほとんどの場合は stored によって透過的に回復および修復されます。ただし、stored が再起動された場合は毎回、デフォルトのログファイルをチェックして、ほかに管理操作が必要ないことを確認してください。データベースをさらに修復する必要がある場合は、ログファイルのステータスメッセージで reconstruct を実行するように示されます。
メッセージストアデータベースを開く前に、stored はデータベースの完全性を分析し、ステータスメッセージを warning のカテゴリの下にあるデフォルトログに出力します。メッセージには管理者にとって有用なものも、内部分析に使用されるコード化されたデータで構成されるものもあります。stored によって問題が検出された場合は、データベースの修復が試行され、再起動が試行されます。
データベースが開くと、stored は、ほかのサービスが起動することを合図します。自動修復が失敗した場合、デフォルトログのメッセージで実行するべきアクションが示されます。詳細については、「reconstruct が必要であることを示すエラーメッセージ」を参照してください。
以前のリリースでは、stored は非常に長い時間がかかる回復プロセスを開始することがあり、stored が「スタック」したかのように見えることがありました。このタイプの長い回復プロセスは取り除かれ、stored は最終的な状態を 1 分以内に判断するようになりました。ただし、stored がスナップショットからの回復などの回復手段を採用する必要がある場合、プロセスは数分かかる場合があります。
ほとんどの回復プロセスでは通常、終了後のデータベースは最新の状態になっていて、ほかに必要な操作はありません。ただし、一部の回復プロセスでは、reconstruct -m を実行してメッセージストアの冗長データを同期させる必要がある場合もあります。これもデフォルトログに示されます。したがって、起動後にデフォルトログを監視することは重要です。メッセージストアが通常どおり起動し、機能しているように見える場合でも、reconstruct など、要求されている操作がある場合は実行することが重要です。
ログファイルを読むもう 1 つの理由は、データベースに障害を引き起こした原因を確認することです。stored は、システムでの問題の種類にかかわらずメッセージストアを回復するように設計されていますが、データベース障害はより大きな問題が潜んでいることの徴候である可能性があるので、原因を解明することをお勧めします。
ここでは、reconstruct の実行が必要なエラーメッセージのタイプについて説明します。
エラーメッセージでメールボックスエラーが示された場合は、reconstruct <mailbox> を実行します。例:
"Invalid cache data for msg 102 in mailbox user/joe/INBOX. Needs reconstruct"
"Mailbox corrupted, missing fixed headers: user/joe/INBOX"
"Mailbox corrupted, start_offset beyond EOF: user/joe/INBOX"
エラーメッセージでデータベースエラーが示された場合は、reconstruct -m を実行します。例:
"Removing extra database logs. Run reconstruct -m soon after startup to resync redundant data"
"Recovering database from snapshot. Run reconstruct -m soon after startup to resync redundant data"
スナップショットは、データベースのホットバックアップであり、壊れたデータベースを数分で透過的に回復するために stored で使用されます。これは、ほかの領域に保存された冗長情報に依存する reconstruct を使用するよりもはるかに速い方法です。
データベースのスナップショット (mboxlist ディレクトリ内) は自動的に作成されます。デフォルトでは、24 時間ごとに作成されます。デフォルトでは、スナップショットは store ディレクトリのサブディレクトリにコピーされます。デフォルトでは、常時 5 つのスナップショットが保存されています。ライブデータベースが 1 つ、スナップショットが 3 つ、データベース/削除済みコピーが 1 つです。データベース/削除済みコピーはより新しいものであり、mboxlist データベースディレクトリの removed サブディレクトリに入れられたデータベースの非常時用のコピーです。
現在のデータベースに障害があるために回復プロセスで削除することが決定されると、stored がデータベースを removed ディレクトリに移動します (可能な場合)。したがって、必要に応じてそのデータベースを分析できるようになっています。
データの移動は、1 週間に 1 度だけ実行されます。データベースのコピーがすでに移動先に存在する場合、stored はストアが起動するたびごとにはコピーを置き換えません。removed ディレクトリのデータが 1 週間よりも古い場合にのみ置き換えます。これは、元のデータベースが一連の起動によってあまりにも早く置き換えられないようにするためです。
データベースとスナップショットを組み合わせるには、5 倍の容量が必要です。スナップショットが別のディスク上で実行されるように再設定し、システムの要件に合わせることを強くお勧めします。
stored によって起動時にデータベースに関する問題が検出された場合は、最善のスナップショットが自動的に回復します。3 つのスナップショット変数を使用して設定できるパラメータは、次のとおりです。スナップショットファイルの場所、スナップショットの作成間隔、保存されるスナップショットの数。表 20–13 に、これらの configutil パラメータを示します。
スナップショットの間隔が短すぎると、システムに頻繁に負荷がかかるとともに、データベースの問題がスナップショットとしてコピーされる可能性が高くなります。スナップショットの間隔が長すぎると、データベースはスナップショットが作成された過去の時点の状態を維持することになります。
スナップショット間隔は 1 日にすることをお勧めします。1 週間またはそれより長い間隔のスナップショットは、システムで問題が数日間解消されない場合に、問題が存在する前の状態に戻すのに便利です。
stored はデータベースの監視を実行し、データベースが完全でない可能性がある場合は最新のスナップショットを拒否する高度な機能があります。代わりに最新のもっとも信頼性の高いスナップショットを取り出します。1 日前のスナップショットが取り出される可能性があることにもかかわらず、システムはより新しい冗長データがある場合はそのデータを使用して古いスナップショットデータを無効にします。
つまり、スナップショットの根本的な役割は、システムを最新の状態に近づけることと、進行中のデータを再構築しようとするシステムのほかの部分の負担を軽減することです。
表 20–13 メッセージストアデータベーススナップショットのパラメータ
パラメータ |
説明 |
---|---|
メッセージストアのデータベーススナップショットファイルの場所です。既存の絶対パスまたは store ディレクトリを基準とする相対パスのいずれかになります。 デフォルト: dbdata/snapshots |
|
スナップショット間隔 (単位: 分) です。有効な値: 1 〜 46080 デフォルト: 1440 (1440 分 = 1 日) |
|
local.store.snapshotdirs |
保存される異なるスナップショットの数です。有効な値: 2 〜 367 デフォルト: 3 |
1 つまたは複数のメールボックスが破損した場合、reconstruct ユーティリティーを使用してメールボックスまたはメールボックスデータベースを再構築し、すべての矛盾を修復することができます。
reconstruct ユーティリティーは、1 つまたは複数のメールボックスまたはマスターメールボックスファイルを再構築し、すべての矛盾を修復します。このユーティリティーを使うと、メールストアにおけるほとんどすべてのデータ破損を回復することができます。詳細については、「reconstruct が必要であることを示すエラーメッセージ」を参照してください。
表 20–14 に、reconstruct オプションの一覧を示します。構文や使用要件の詳細については、『Sun Java System Messaging Server 6.3 Administration Reference』の「reconstruct」を参照してください。
表 20–14 reconstruct オプション
オプション |
説明 |
---|---|
-e |
再構築の前に、store.exp ファイルを削除します。これは、ストア処理によって消去されなかった削除済みメッセージの内部ストアレコードを除去します。-i または -e を使用するときに -f オプションも使用すると役立ちます。これは、これらのオプションはフォルダが実際に再構築された場合にのみ機能するからです。同様に、-n オプション (再構築ではなくチェックを実行する) を使用する場合は、-i および -e オプションは機能しません。 reconstruct が破損を検出しない場合は、reconstruct -e は削除済みメッセージを復元しません。-f は、再構築を強要します。 |
-i |
再構築の前に、store.idx ファイル長を 0 に設定します。-i または -e を使用するときに -f オプションも使用すると役立ちます。これは、これらのオプションはフォルダが実際に再構築された場合にのみ機能するからです。同様に、-n オプション (再構築ではなくチェックを実行する) を使用する場合は、-i および -e オプションは機能しません。 |
-f |
reconstruct に 1 つまたは複数のメールボックスで修復を行うように強制します。 |
-l |
lright.db を再構築します。 |
-m |
整合性チェックを行い、必要に応じてメールボックスデータベースを修復します。このオプションを使用すると、スプールエリアで見つかったすべてのメールボックスがチェックされ、必要に応じてメールボックスのデータベースエントリの追加または削除が行われます。データベースでエントリの追加または削除が行われると、メッセージが標準出力ファイルに出力されます。つまり、folder.db、quota.db、および lright.db を修復します |
-n |
メールボックスの修復を実行せずに、メッセージストアだけをチェックします。メールボックス名を指定せずに、-n オプションを単独で使用することはできません。メールボックス名を指定しない場合、-n オプションは -r オプションとともに使用する必要があります。-r オプションは、-p オプションと組み合わせることもできます。たとえば、次のコマンドはすべて有効です。 reconstruct -n user/dulcinea/INBOX reconstruct -n -r reconstruct -n -r -p primary reconstruct -n -r user/dulcinea/ |
-o |
廃止。mboxutil -o を参照してください。 |
-o -d filename |
廃止。mboxutil -o を参照してください。 |
-p partition |
-p オプションを -m オプションとともに使用し、再構築の範囲を指定されたパーティションに制限します。-p オプションを指定しない場合、reconstruct はデフォルトですべてのパーティションを再構築します。つまり、folder.db および quota.db を修復しますが、lright.db は修復しません。これは lright.db を修復すると、メッセージストア内のすべてのユーザーに対して ACL のスキャンを実行する必要があるためです。これをすべてのパーティションに対して実行するのは効率的でありません。lright.db を修復するには、reconstruct -l を実行します。 パーティション名を指定します。完全なパス名は使用しないでください。 |
-q |
制限容量サブシステムの矛盾 (メールボックスの制限容量ルートが正しくない、または制限容量ルートで誤った容量の使用状況がレポートされるなど) を修正します。-q オプションは、ほかのサーバープロセスの実行中に実行できます。 |
-r [mailbox] |
指定した 1 つまたは複数のメールボックスのパーティションエリアを修復し、整合性をチェックします。また、-r オプションは、指定したメールボックス内のすべてのサブメールボックスも修復します。-r を指定してメールボックス引数を入力しなかった場合は、ユーザーパーティションディレクトリ内にあるすべてのメールボックスのスプールエリアが修復されます。 |
-u user |
-u オプションを -m オプションとともに使用し、再構築の範囲を指定されたユーザーに制限します。-u オプションは、-p オプションとともに使用する必要があります。-u オプションを指定しない場合、reconstruct はすべてのパーティションまたは -p オプションで指定されたパーティションを再構築します。 ユーザー名を指定します。完全なパス名は使用しないでください。 |
メールボックスを再構築するには -r オプションを使用します。このオプションは次の場合に使用します。
メールボックスにアクセスしたら、「システム I/O エラーが発生しました」または「メールボックスのフォーマットが不正です」のどちらかのエラーが返された場合。
メールボックスにアクセスしたらサーバーがクラッシュした場合。
ファイルがスプールディレクトリに追加されたか、スプールディレクトリから削除された場合。
reconstruct -r は、最初に整合性チェックを行います。問題が検出された場合にのみ、すべての整合性を報告し、再構築を行います。したがって、このリリースでは reconstruct ユーティリティーのパフォーマンスが向上しています。
reconstruct は、次の例で説明するように使用することができます。
ユーザー daphne に属するメールボックスのスプール領域を再構築するには、次のコマンドを使用します。
reconstruct -r user/daphne
メールボックスデータベースに一覧表示されたすべてのメールボックスのスプール領域を再構築するには、次のように入力します。
reconstruct -r
ただし、このオプションは注意して使用してください。メールボックスデータベースに一覧表示されたすべてのメールボックスのスプール領域を再構築する場合、メッセージストアが大規模なため非常に長い時間を要する可能性があるからです。(「20.14.3.3 reconstruct のパフォーマンス」を参照。) これよりも優れた障害復旧に対する手段は、ストア用に複数のディスクを使用することでしょう。ディスクが 1 つダウンしてもストア全体がダウンすることはないからです。ディスクが破損した場合、次のように -p オプションを使用してストアの一部分を再構築するだけですみます。
reconstruct -r -p subpartition
コマンド行の引数にリストされたメールボックスが primary パーティションに存在する場合のみそれらを再構築するには、次のように入力します。
reconstruct -p primary mbox1 mbox2 mbox3
primary パーティションに存在するすべてのメールボックスを再構築する必要がある場合は、次のようになります。
reconstruct -r -p primary
整合性チェックを実行せずにフォルダを再構築する場合は、-f オプションを使用します。たとえば、次のコマンドはユーザーフォルダ daphne の再構築を実行します。
reconstruct -f -r user/daphne
すべてのメールボックスを修正せずにチェックする場合は、次のように -n オプションを使用します。
reconstruct -r -n
高レベルの整合性チェックを行い、メールボックスデータベースを修復するには、次のように入力します。
reconstruct -m
整合性チェックを行い、プライマリパーティションを修復するには次のように入力します。
reconstruct -p primary -m
-p および -m フラグを指定して reconstruct を実行しても、lright.db は修復されません。これは lright.db を修復すると、メッセージストア内のすべてのユーザーに対して ACL のスキャンを実行する必要があるためです。これをすべてのパーティションに対して実行するのは効率的でありません。lright.db を修復するには、reconstruct -l を実行します。
整合性チェックを行い、john という名前のユーザーのメールボックスを修復するには次のように入力します。
reconstruct -p primary -u john -m
-m オプションは次の場合に使用します。
1 つまたは複数のディレクトリがストアスプール領域から削除されたため、メールボックスデータベースのエントリも削除する必要が生じた場合。
1 つまたは複数のディレクトリがストアスプール領域に復元されたため、メールボックスデータベースのエントリも追加する必要が生じた場合。
stored -d オプションによってデータベースの整合性を保つことができない場合。
stored -d オプションによってデータベースの整合性を保つことができない場合、次の手順を順番に実行します。
すべてのサーバーを停止します。
store_root/mboxlist 内のすべてのファイルを削除します。
サーバープロセスを再起動します。
reconstruct -m を実行して、スプール領域の内容から新しいメールボックスデータベースを構築します。
reconstruct が処理を実行するのにかかる時間は、次に示すいくつかの要素によって異なります。
実行される処理と選択したオプションの種類
ディスクパフォーマンス
reconstruct -m 実行時のフォルダの数
reconstruct -r 実行時のメッセージの数
メッセージストアの全体サイズ
システムが実行するほかのプロセスとシステムのビジー状態
実行中の POP、IMAP、HTTP、または SMTP アクティビティーが存在するかどうか
reconstruct -r オプションにより、最初の整合性チェックが実行されます。このチェックでは、再構築の必要なフォルダの数に応じて reconstruct のパフォーマンスが向上します。
ユーザー数が約 2400、メッセージストアが 85G バイトで、POP、IMAP、または SMTP アクティビティーが同時にサーバーで実行されているシステムでは、次のパフォーマンスが得られました。
reconstruct -m に要した時間は約 1 時間
reconstruct -r -f に要した時間は約 18 時間
reconstruct の操作にかかる時間は、サーバーで POP、IMAP、HTTP、または SMTP アクティビティーが実行されていない場合、大幅に減少します。
この節では、次のようなメッセージストアの一般的な問題と解決策の一覧を示します。
このパッチのインストール後、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 |
ユーザーが Messenger Express ページまたは Communications Express メールページを読み込めない場合は、圧縮後にデータが破損している可能性があります。これは、古いプロキシサーバーがシステムに配備されている場合に発生することがあります。この問題を解決するには、local.service.http.gzip.static および local.service.http.gzip.dynamic を 0 に設定して、データ圧縮を無効にしてください。これで問題が解決したら、プロキシサーバーを更新することができます。
UNIX シェルには、ワイルドカードパターンを引用符で囲む必要があるものとその必要のないものがあります。たとえば、C シェルはワイルドカード (*、?) を含む引数をファイルとして展開しようとするため、一致するものがない場合は失敗します。これらのパターンマッチング引数は、mboxutil のようなコマンドに渡すためには引用符で囲む必要があります。
次に例を示します。
mboxutil -l -p user/usr44*
これは Bourne シェルで機能しますが、tsch や C シェルでは失敗します。これらのシェルには次のコマンドが必要です。
mboxutil -l -p "user/usr44*"
ワイルドカードパターンを使用したコマンドが機能しない場合は、そのシェルではワイルドカードを引用符で囲む必要があるかどうかを確認してください。
ユーザーのメールボックスが作成したばかりの新しいパーティションに移動され、Messaging Server が更新または再起動されていない場合、Messenger Express で「パーティションが不明または無効です」というメッセージが表示されることがあります。この問題は新しいパーティションでのみ発生します。この新しいパーティションにユーザーメールボックスを新しく追加する場合、Messaging Server の更新または再起動を行う必要はありません。
ユーザーメールボックスに関する問題が発生するのは、メッセージストアの損傷が少数のユーザーに限られていて、システム全体に対する損傷がないときです。ユーザーメールボックスのディレクトリに関する問題を識別、分析、および解決する際は、次のガイドラインを参考にしてください。
ログファイル、エラーメッセージ、またはユーザーが見た異常な動作を確認します。
デバッグ情報と履歴を保存しておくには、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 メールボックスとメールボックスデータベースの修復」を参照してください。
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 とグループに変更します。
メッセージストアには 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」を参照)、アーカイブシステムの設定、またはメールボックスのサイズを抑制するためのなんらかの措置を行う必要があります。