qmail導入・運用関連トラブルシューティング集：実用qmailサーバ運用・管理術（12）（2/2 ページ）

[鶴長鎮一，＠IT]

運用開始後のトラブル

　インストール以上に、運用のスタイルはさまざまです。そのため十把ひとからげにはできませんが、いくつか例を挙げてみましょう。

ユーザーの受信メールでディスクがあふれてしまった

　qmailでMaildirを使用している場合、受信メールは各ユーザーのホームディレクトリに1メッセージ1ファイルで保存されます。ここで問題になるのはディスクの容量ですが、重要なのは物理的な容量よりも、どれだけ多くのファイルを格納できるかです。

　Linuxで用いられているext2やext3をはじめとするUNIX FILE SYSTEMを起源に持つファイルシステムでは、データ格納領域とは別に、iノードと呼ばれるファイルの属性を記録する領域があります。具体的には、ファイル所有者、タイムスタンプ、ファイルのデータブロックのアドレスなどの情報が記録されます。

　Linuxをインストールする際（ファイルシステムを作成する際）、特に指定しなければiノードは4096bytesごとに作成されます。パーティションに対するiノードの個数が、そのパーティションに保存できるファイルの数に相当します。もし、4096bytes未満のファイルが大量に蓄積されていくと、ディスクの容量が満たされる前にiノードを使い切ってしまうことになります。

　まず、現状でどれだけiノードを消費しているか、「df -i」で確認します。

$ df
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/sda3             10135800   8369536   1251384  87% /
/dev/sda1                38859     17523     19330  48% /boot
/dev/sda2             20641788  11165928   8427220  57% /var

通常のdfではファイルの使用容量を表示

$ df -i
Filesystem            Inodes   IUsed   IFree IUse% Mounted on
/dev/sda3            1289280  731407  557873   57% /
/dev/sda1              10040      63    9977    1% /boot
/dev/sda2            2626560  743039 1883521   29% /var

-iを指定することで、iノードの使用状況を表示

　iノードの使用量が限界に近いようであれば、新たに容量の大きなディスクを用意するか、いったん受信ファイルのバックアップを取った後、再度ディスクに対してmke2fsを実行することになります。

　mke2fsでiノードの作成単位を4096bytes以外にする（注）には、次のように-iオプションに続けて数値を指定します。

# mke2fs -i 1024 -c /dev/hdb1

IDEハードディスク（hdb）の1番目のパーティションに対してiノード1024bytesを指定した場合

　ディスクを増設する手順は、「Linux Tips：HDDを増設するには」を参考にしてください。

注：iノードの作成単位を小さくすると、それだけ多くのiノード領域が確保されるため使用できるデータ領域は減少します。逆に、iノードの作成単位を大きくすればデータ領域の減少を低減できます。ディスクの容量分を丸々使えない理由がここにあります。

　/var/qmail/queueがあふれるような場合は、「第3回　SPAMメール徹底対策」で紹介した、qmHandleを有効に活用します。

ログの意味が分からない

　/var/log/maillogや/va/log/qmailなど、出力されるログの意味はqmail-logのマニュアルを見ることで解決できます。マニュアルの日本語訳がhttp://www.jp.qmail.org/q103/jman5/qmail-log.htmlにあります。

　ログメッセージの重要度は以下のようになっており、下のものほど重要度が高くなります。WARNING以上が出るようなら、対策を講じる必要があります。

• 動作状況（STATUS）
• メッセージ（MESSAGES）
• 配送（DELIVERIES）
• 警告（WARNINGS）
• 重大な問題（SERIOUS PROBLEMS）
• 致命的な問題（FATAL PROBLEMS）

　iノードとデータ領域の話を前述しましたが、ディスクの監視を怠ってしまってもログにしっかり証拠が残ります。「trouble writing to ...」と記録された場合の多くはディスクがいっぱいになったときで、「unable to create ...」はiノード不足になったことを意味します。

　普段からログに目を通す癖をつけておけば、大きな障害が発生する前にトラブルを解決することで、大事に至らないで済みます。もし、ユーザー全員のMaildirが消失したら……と考えると、身も凍る思いですよね。

トラブルシュートに必要な知識とは

　今回はトラブルシューティングとして、いくつかの障害事例と解決策を紹介しました。そのものズバリの解決策が見つかった方は少ないかもしれませんが、せめて解決のきっかけになればと思います。

　紹介した事例を見て感じた方も多いと思いますが、qmailの障害対応をうたいながらも、多くはLinuxに対する知識を必要としていることがほとんどです。qmailに対する知識を深める一方で、Linuxに対するそれも同じように深めていければ、初見の障害にも対応できる力がきっと備わるはずです。

「次回」へ

「実用qmailサーバ運用・管理術」バックナンバー

• qmailをより使いこなすTips（便利な小技編）
• qmailをより使いこなすTips（インストール関連編）
• qmail導入・運用関連トラブルシューティング集
• qmailのパフォーマンス・チューニング
• ツールを使った効率的なログ分析術
• daemontoolsによるロギングとプロセス監視
• メールサーバで行うウイルス対策
• GUI管理ツールの導入とユーザー情報のSQL化
• バーチャルドメインにおけるqmailの運用
• メーリングリストの構築と運用（後編）
• メーリングリストの構築と運用（前編）
• SPAMメール徹底対策
• POP／IMAPサーバの構築と不正中継対策
• qmailによるSMTPサーバの構築