Natz's Digital 漂流記

先日我が家で VMware Server 2.0.2 が稼動する親機も含め、全ての CentOS 5.x を5.3 → 5.4 にアップグレードしたのは既報の通りだが、VMware Server 2.0.2 上で仮想マシン (以下 VM) が突如落ちる不具合に見舞われ、実はけっこう困っていた。具体的には、CentOS 5.4 上の VMware Server 2.0.2 で VM の CentOS 5.4 を起動してしばらくすると (タイミングは不定)、何の前触れもなく突然 VM が死ぬと言う現象だ。これが発生すると、VI Web Access や vmware-vim-cmd 等で VM の操作ができなくなるので、全ての VM に SSH 等の手段で個別にログインしてシャットダウンし、VMware Server を停止。残ったプロセスを殺して *.lck ディレクトリや *.vmem ファイルの残骸を削除し、VMware Server を再起動、と言う面倒なことになる。しかもこれが頻発すると来れば、実に厄介だ。

当初は VMware Server 2.0.2 の不具合かと思ったが、アップグレードする前の 2.0.1 で既に 1回発生していたことを思い出して同様の症例を探すと、ここやここで見つかった。やはり CentOS 5.4 のアップグレードに起因する問題だ。

これらのページによると、どうも glibc 2.5-42 と vmware-hostd が具合が悪いらしい。これから CentOS 5.4 にする場合は yum.conf で exclude すべしとあるが、僕のように既にやってしまった場合は、手動でダウングレードしなければならない。とりあえず yum downgrade を試すと、CentOS 5.4 では 2.5-42 より前のバージョンは存在しないと言われてしまったので、5.3 の最後の glibc を使うことにする。

まず rpm -qa | grep glibc | sort 等で、必要なパッケージを確認する。僕は既にインストールされていた以下のパッケージをここからダウンロードした (x86_64 の場合。i386 はこちら)。パッケージの入手先は、CentOS 5.x のリポジトリならどこでも OK。

(2010-07-26 追記)
CentOS 5.5 がリリースされた現在は、上記リポジトリが空になっていた。新たに該当 RPM を入手する場合は、RPM Search 等でどうぞ。RPM Search の場合は、"Advanced RPM Search" の "RedHat EL 5" のチェックを ON にし、各パッケージを個別に検索すれば ("glibc-2.5-34.el5_3.1" 等) 見つかるはず。SRPM からビルドしても OK。

1. glibc-2.5-34.el5_3.1.i686.rpm
2. glibc-2.5-34.el5_3.1.x86_64.rpm
3. glibc-common-2.5-34.el5_3.1.x86_64.rpm
4. glibc-devel-2.5-34.el5_3.1.i386.rpm
5. glibc-devel-2.5-34.el5_3.1.x86_64.rpm
6. glibc-headers-2.5-34.el5_3.1.x86_64.rpm
7. nscd-2.5-34.el5_3.1.x86_64.rpm

nscd は glibc との依存関係のため、ついでにダウングレード。当初 glibc 関連パッケージだけでダウングレードを敢行したところ ncsd の依存関係で失敗し、モノがモノだけにかつて味わった RPM 地獄の記憶が蘇って戦慄したが、nscd のみで助かった。便利なパッケージ管理ツールが一般的でなかった時代には、何か RPM をインストールしようとすると次から次へと依存関係が出て来て、必要なパッケージが入手できずに断念する羽目になったり、パッケージ間のバージョンの差異で収拾がつかなくなる等、悲惨な目に遭ったものだ。

ダウングレードの際には、必要なパッケージを任意のディレクトリにまとめておくと、個別に rpm コマンドを実行する手間が省ける。

この後 VMware Server 2.0.2 をいったんアンインストール (vmware-uninstall.pl または rpm -e VMware-server) し、改めてインストールし直す。また同じトラブルの再発を防ぐため、この glibc 問題が解決するまでは、yum.conf の exclude に "glibc*" と "nscd*" を登録しておく。

しばらく CentOS 5.4 上で VM を複数稼働させて様子を見てみたところ、不具合は解消されたように見える。今回の glibc もそうだが、カーネルや nss_ldap (我が家は Windows と Linux のユーザー・アカウントを OpenLDAP で管理している) 等、他のディストリビューションも含めて過去に不具合発生実績があり、かつその影響が大きいパッケージの更新はスリリングだ。

One Response to this entry.