Nagios 3.2.2-1 へのアップデート後に Nagios の起動に失敗する

CentOS 5.4 の環境で Nagios 3.2.0-1.el5 を利用していたのですけど、あるときこれを yum を使って Nagios 3.2.2-1.el5 にアップデートしてみたところ、Nagios の起動が出来なくなってしまいました。

これまでにも別の環境ではありますが、EZ-NET レポート： 監視ツール Nagios を 3.2.0 にアップデートしてみる や EZ-NET: yum でアップデートした後に Nagios が起動できなくなる といったように、Nagios はアップデートのたびに起動できなくなっているような印象があり、そういう面ではあまり好感の持てない感じです。

今回も Nagios をアップデートした後で、また動かなくなっているのではないかと "service nagios restart" を実行してみたところ、動かなくなっていることが確認されたのでした。

 

ともあれ、今回の起動に失敗する原因を調べてみたところ、どうやら Nagios プロセスが何らかの理由でロックファイルを書き出す権限が無くなってしまったために、起動に失敗してしまっている様子が伺えました。

もっとも、自分で起動アカウント名を "nagios" から別のアカウント名に調整していたりといったこともあったのですけど、起動スクリプトの内容が変わって新しいものに差し替えられてしまったり、新しい環境を想定した設定ファイルが "/etc/nagios/nagios.cfg.rpmnew" というファイルで退避された状態でインストールされたりと、新旧設定が混ざってしまったことも、起動できなくなった理由の一つなのかもしれません。

 

Nagios の起動アカウントは "/etc/rc.d/init.d/nagios" 内の "user" の値と、"/etc/nagios/nagios.cfg" 内の "nagios_user" の値との両方で設定されています。

今回のアップデートで、前者は Nagios 側が用意した新しいファイルに、後者はこちらで用意した旧ファイルになってしまったため、これらに記載されているアカウント名が食い違ったことが、起動できないひとつの原因となっていました。

このとき "service nagios restart" 等をしようとすると、"runuser: nagios というユーザは存在しません" というエラーが表示されてしまってました。

 

上記 2 ファイルの起動アカウントを適切なものに統一して、再度 "service nagios restart" を実行しようとしてみたところ、今度は何もエラーの表示なく、Nagios の起動が [NG] となってしまいました。

幸い /var/log/message にはエラーログが残されていて "Failed to obtain lock on file /var/run/nagios.pid: 許可がありません" というエラーが検出されているようです。

調べてみると /var/run ディレクトリーへは root 権限でないとファイルを作成できないように制限されているのですが、従来から使っていた /etc/nagios/nagios.cfg の中の lock_file の値では、このディレクトリー内にロックファイルを作成する設定になっていたのでした。

今回のアップデートで、退避された形でインストールされた nagios.cfg.rpmnew を確認してみると、このロックファイルの場所が /var/nagios ディレクトリーになっています。

今回のアップデートで、ロックファイルを書き出す実効アカウントが root ではなくなった様子が伺えますが、それでも、/var/nagios ディレクトリーは nagios アカウントでも読み込みだけはできるものの、書き込みは root でなければできない感じになっていました。

結局のところ、nagios.cfg の lock_file を "/var/nagios/nagios.pid" に変更の上、/var/nagios ディレクトリーを含めた中の全てのディレクトリーを nagios アカウントが所有するようにすることで、ようやく Nagios が起動できるようになりました。