daemontoolsによるロギングとプロセス監視：実用qmailサーバ運用・管理術（9）（1/3 ページ）

syslogを使ったロギングにはいくつかの欠点がある。そこで、ロギングやプロセス監視を行ってくれるdaemontoolsを導入しよう。これにより、システムをより強力なものにできる。

[鶴長鎮一，＠IT]

　ログは、サーバの状態やプロセスの稼働状況を知るうえで欠かせない情報源です。管理者がコンソールに向かっていない間に発生した障害も、ログを頼りに復旧したり原因を探って再発を防ぐ手段を講じることができます。新たにインストールしたツールがうまく動作しない場合にも、ログを見ればどこの手順で間違ったのか、どこがうまくいっていないかを知ることができます。

　Apacheをはじめとする最近のツールは、標準のコンフィグレーションでロギングが有効になっています。「ApacheによるWebサーバ構築」第14回 ログローテーションとAnalogの導入では、Apacheのログを分析ツール「Analog」を使用してグラフ化する方法が紹介されています。グラフ化ツールは、ネットワーク監視（参考：運用管理に必須のツール／コマンド群）では定石です。もちろん、qmailでも可能です。

　まず、前回までのインストールで使用したログについて整理し、その後ロギングだけでなくプロセスの監視も行うDJBツール（注）のdaemontoolsを紹介します。

注：qmailの作者であるD. J. Bernstein氏が提供するパッケージを総称して「DJBツール」と呼んでいます。

sploggerを使ったロギング

　POPサーバを取り上げた第2回以降では、rc起動スクリプトに「splogger」を併用することで/var/log/messagesまたは/var/log/maillogにログを出力させていました。

start)     （中略）         tcpserver -v 0 pop3 /var/qmail/bin/qmail-popup [サーバのFQDN] /bin/checkpassword \         /var/qmail/bin/qmail-pop3d Maildir 2>&1 \                 | /var/qmail/bin/splogger pop3d 3 &         echo         touch /var/lock/qmail         ;;

第2回 POP／IMAPサーバの構築と不正中継対策より

　sploggerは、サーバにインストールされているsyslogdデーモンを利用しているため、ログの出力先は/etc/syslog.confで決定されます。ログが/var/log/maillogに出力されている場合は、/etc/syslog.confに次のような行があるはずです。

mail.*                                              /var/log/maillog

/etc/syslog.conf

Apr 12 19:38:02 ホスト名 qmail: 1018607882.966157 status: exiting Apr 13 03:59:53 ホスト名 qmail: 1018637993.607186 status: local 0/10 remote 0/20 Apr 13 04:11:28 ホスト名 qmail: 1018638688.274493 status: exiting Apr 13 04:11:38 ホスト名 qmail: 1018638698.078697 status: local 0/10 remote 0/20 Apr 13 04:12:48 ホスト名 qmail: 1018638768.855360 new msg 375121 Apr 13 04:12:48 ホスト名 qmail: 1018638768.855520 info msg 375121: bytes 497 from <> qp 14533 uid 3009

/var/log/maillogの例

　/etc/syslog.confの前半の識別子が「facility」と呼ばれるもので、後半が出力先ファイル名になります。sploggerのデフォルトfacilityが「mail facility (LOG_MAIL)」であるため、知らぬ間にログを蓄えていたわけです。qmail-smtpdやqmail-pop3dのログを分離したい場合は、sploggerの引数にfacilityを指定し、そのfacilityに対する出力先を/etc/syslog.confに指定します。例えば、上記のpop3dを起動するスクリプトではsploggerでfacility 3が指定されています。

.....省略 | /var/qmail/bin/splogger pop3d 3 &

　この場合、/etc/syslog.confで次の行が有効となり、/var/log/messagesに「pop3d」という目印付きで出力されます。facilityを数字で表した場合と「mail」などのニーモニックで表した場合の対比は/usr/include/syslog.hを参照してください。

*.info;mail.none;news.none;authpriv.none                                 /var/log/messages

/etc/syslog.conf

　このように汎用性に優れたsyslogdですが、多用することはあまりお勧めできません。syslog機構はログメッセージが完全に記録されることを保証していないため、信頼できないことを考慮する必要があります。また、非常に遅いことも知られています。そこで、「daemontools」を導入しましょう

daemontoolsの活用

　daemontoolsは、先に紹介したようにqmailの作者であるD. J. Bernstein氏により提供されているパッケージです。以前のバージョンでは、パッケージに含まれるロギングツール「cyclog」を使用したいがためにインストールする管理者を多く見受けました。バージョン0.61からはこれが「multilog」に置き換わり、さらにプロセス監視機能「svscan」が強化されました。最近ではsvscanをメインで使用することも多くなりつつあるようです。

　daemontoolsには次のようなメリットがあります。

• syslogと異なりソケットの代わりにパイプを使用するため、ログが確実に取れる
• ログの容量を監視してくれる。ログのローテーションは日付ではなく、ある一定容量に達したかどうかによって行われる
• サービスの追加・削除が簡単にできる。システム起動時に自動的に開始するか否かも簡単に指定できる
• サービスを監視するためのロックファイルを作らなくて済む
• デーモンのPIDを直接調べなくてもシグナルが送れる。daemontoolsを使って走らせた各デーモンはPIDではなく名前で指定でき、複数のデーモンにシグナルを送ることも可能
• 起動するデーモンごとにlimitがかけられる。これにより、メモリ使用量やユーザー権限を制限できる参考：http://www.unixuser.org/~euske/doc/daemontools/myfaq/faq-1.html#3

daemontoolsのインストール

　では、daemontoolsの導入を順に見ていきましょう。最新版であるdaemontools-0.76.tar.gzをhttp://cr.yp.to/daemontools/install.htmlからダウンロードし、適当な作業ディレクトリに保存します。また、インストールの際は/packageディレクトリを用意し、そのディレクトリ下で作業する必要があります。/（ルート）にディレクトリを作ることに抵抗を感じる方もいると思いますが、パッケージに含まれるinstallスクリプトを実行するためには避けられない作業です。

# mkdir -p /package

注：-pオプションは通常、存在しない親ディレクトリも含めて作成する場合に用います。例えば、「mkdir -p /tmp/1/2/3」を1回実行するだけで、「/tmp/1」「/tmp1/2」「/tmp/1/2/3」の3つのディレクトリが作成されます。すでに存在するディレクトリに対して実行した場合は無視されます。ディレクトリ/aが存在する場合に「mkdir /a」とするとエラーを返しますが、「mkdir -p /a」はエラーになりません。

　次に、/packageディレクトリに対して適切なパーミションを設定します。その際、スティッキービット（注）も付加します。

# chmod 755 /package # chmod +t /package

「# chmod 1755 /package」の一発実行でも同じ

注：スティッキービットは、HD上のスワップ領域に粘り付き（stick）動作させるという意味も持ち、プログラムコードをスワップ上に維持することを指しています。ただし、一般的には全ユーザーに書き込みを許可しながらも所有者以外は削除できないという特徴から、たびたび使用されます。

　パーミッションを設定したら/packageディレクトリに移動し、daemontools-0.76.tar.gzファイルを展開してその中に含まれるinstallスクリプトを実行します。

# cd /package # tar xvpfz 保存したディレクトリ/daemontools-0.76.tar.gz # cd admin/daemontools-0.76 # ./package/install

　以上の作業で、以下のディレクトリとファイルが作成されます。

• 新たに作成されるディレクトリ
  /service
  /command
• 作成されるファイルおよびそのシンボリックリンク
  /package/admin/daemontools/command/下に実行ファイル
  /command/下にそのシンボリックリンク
  /usr/local/bin/下にさらにシンボリックリンク

　また、/etc/inittabファイルの末尾に次の1行が追加されます。

SV:123456:respawn:/command/svscanboot

/etc/inittab

　inittabの変更を有効にするには「kill -HUP 1」を実行する必要がありますが、installスクリプトですでに実行されています。確認のため、svscan関連のコマンドが起動されているかどうかをpsコマンドで見ておきましょう。

# ps -aef | grep svscan root      1102     1  0 11:44 ?        00:00:00 sh /command/svscanboot root      1104  1102  0 11:44 ?        00:00:00 svscan /service

　これでインストールは完了です。次に、daemontoolsが適切に日付を処理できているかを確認します。出力の左と右で時間が同じであれば問題ありません。

# cd /command/ # date | ./tai64n | ./tai64nlocal 2002-05-14 03:54:59.114461500 Tue May 14 03:54:59 JST 2002 # date | sh -c './multilog t e 2>&1' | ./tai64nlocal 2002-05-14 03:55:21.425022500 Tue May 14 03:55:21 JST 2002

　ここで、「TAI64N形式」のタイムスタンプについて説明する必要があります。先ほどの導入のメリットには加えませんでしたが、daemontoolsを使用することでナノ秒精度でのロギングが可能になります。実質的にはマシンクロックで制限されますが、それでもマイクロ秒の精度です。それを実現する基盤がTAI64Nです。ここで使用したtai64nとtai64nlocalコマンドは、通常私たちが認識できる日付フォーマットで出力させるためのものです。これについては後ほどあらためて紹介します。

参考：TAI「Temps Atomique International」（国際原子時間International Atomic Timeのフランス語）http://tehanu.hpcl.titech.ac.jp/time/utctai.html）

daemontoolsによるプロセス監視

　併せて、プロセス監視の仕組みも理解しておきましょう。通常のrc起動スクリプトはサーバが起動される際に1度実行されるだけで、異常終了には関知しません。そのため、管理者はプロセスが起動しているかをpsコマンドで確認するか、cronを利用してプロセスが起動されていない場合は再立ち上げするようなスクリプトを作成して対処します。経験された方なら、そのために払われる労力が相当なものだと理解できると思います。商用サービスを展開しているところでは、専用監視ツールを導入することも少なくないと思います。しかし、実際の運用において、プロセスが毎日のように落ちることはまれです（注）。まれに発生する障害に対して並々ならぬ努力が払われているプロセス監視ですが、これらの煩わしい作業をsvscanプロセスが代行します。

注：頻繁に落ちるような状況に必要なのは、監視ではなく落ちないようにする対策です。

　daemontoolsの導入によってインストールされたsvscanプロセスは、常に/serviceディレクトリを5秒置きに監視します。/serviceディレクトリにサブディレクトリsubが存在する、または作成された場合、1つのsubに対し1つのsuperviseコマンドを立ち上げます。もし、superviseプロセスが終了していないサービスを発見した場合、そのsuperviseプロセスを再開させます。

　superviseコマンドはサブディレクトリ（ここではsubとします）に移動して./runスクリプトを起動させ、プロセスを監視します。この./runにはサービスを実行するスクリプトを記述しておきます。subにスティッキービットが立っている場合は、さらにsub中のlogディレクトリに移動して、新しいsuperviseコマンドを立ち上げます。新しいsuperviseコマンドはlogディレクトリ中の./runスクリプトを起動して監視します。この./runスクリプトに、ログを記録するようにmultilogの実行を記述しておきます。2つのsuperviseコマンドは1組と見なされ、sub/runの出力とsub/log/runの入力はパイプでつながれます。これが、漏れのないログ記録を実現するゆえんです。

図1

　ここで注意しなければいけないのは、新規にsuperviseでプロセスを起動したい場合、/serviceディレクトリにサブディレクトリを作りスティッキービットを立てる作業を5秒以内（実際にはもっと短い間隔）で終了させる必要があることです。svscanはディレクトリの属性変更を感知しないため、最初にサブディレクトリを見つけた際の属性をその後も引き継ぎます。

　これを回避するには、「mkdir /service/sub;chmod +t /service/sub」と一気に一連の作業を行うか、/service以外のディレクトリで起動のためのディレクトリやファイルを用意しておき、準備が完了した時点で/service下にシンボリックリンクを作成するかです。今回は、/var/qmail/service下で起動の準備を行い、シンボリックリンクを作成する方法を使います。