先日 OpenLDAP の Slave サーバーを担当する VMware ESXi 上の仮想マシン (以下 VM) の CentOS 5.5 で再起動をかけたところ、いつまで経っても起動が完了しない。妙だなと vSphere Client でコンソールを開いてみると、以下のエラー・メッセージと共に OS の起動プロセスが止まっていた。

Checking configuration files for slapd:  bdb_db_open: unclean shutdown detected; attempting recovery.
bdb_db_open: Recovery skipped in read-only mode. Run manual recovery if errors are encountered.

強制シャットダウンしたわけでもないし、OpenLDAP のデータが破損するような心当たりはなかったが、中途半端なところで OS の起動が止まっているせいで SSH ログインもできず (まだ sshd が起動していない)、どうにもならない。

仕方がないので、VM をリセットしてシングル・ユーザー・モードで OpenLDAP の自動起動を無効にし、とりあえず OS を普通に起動。改めて slapd を起動させてみると、次のような反応が返って来た。

・slapd を起動。
# /etc/init.d/ldap start
Checking configuration files for slapd:  bdb_db_open: unclean shutdown detected; attempting recovery.
bdb_db_open: Recovery skipped in read-only mode. Run manual recovery if errors are encountered.
(ここで止まってしまうので、[Ctrl]+[C])
                                                           [  OK  ]
Starting slapd:                                            [  OK  ] ← 起動したらしい

・改めて再起動。
# /etc/init.d/ldap restart
Stopping slapd:                                            [  OK  ]
Checking configuration files for slapd:  config file testing succeeded
                                                           [  OK  ]
Starting slapd:                                            [  OK  ] ← 今度は普通に起動した

今回は slapd の再起動だけで復旧したが、slapd を再起動しても同じエラーが表示される場合は、データに何らかの不具合が発生している可能性があるので、無事に解消できることを祈りつつ、次のように slapd_db_recover を実行する。

・OpenLDAP のデータ不整合 (?) を解消
# slapd_db_recover -h /var/lib/ldap ← データ・ディレクトリを指定

しかしこの現象が今回の VM 同様に OpenLDAP の Slave でもある実家のファイル・サーバー (CentOS) で発生していたらと考えると、背筋が寒くなる。実家の家族に 「シングル・ユーザー・モードで slapd 止めといて」 と説明して通じるわけはないし、GRUB の操作から自動起動設定云々を電話で説明してやってもらうのは、100% 不可能。事前にサーバー機に Windows XP マシンの液晶ディスプレイをつなぎ代え、普段は外してあるキーボードを接続する時点で、作業のハードルとしては十分過ぎるほどに高い。

こんなくだらないことで帰省する羽目になっては堪らないので、OpenLDAP は Master と Slave 共に自動起動を無効にして、起動スクリプトを rc.local から "&" 付きで叩くようにした。他にも Zabbix や Puppet で管理する等の方法があるが、とにかく OS が起動中に止まることだけは回避しなければ。

Comments are closed.