CentOS5でのyum update実行時に「Cannot open logfile //var/log/yum.log」となる場合の解決方法

CentOS5のコンソール画面で

yum update -y

と実行すると、

Cannot open logfile //var/log/yum.log

というエラーになり、yum updateが失敗することがある。

エラーメッセージの

Cannot open logfile //var/log/yum.log

は、「/var/log/yum.logというログファイルを開くことができません」という意味なので、「ファイルを開くことができない・・・ファイルのパーミッションの問題かな」と推測し、lsコマンドでファイルのパーミッションを確認すると、衝撃的な事実が分かるかもしれない。

《例》
[root@neko ~]# ls -ahl /var/log/yum.log
---x-wx-wT 26827 518144265 954210578 7.5E Mar 27 1911 /var/log/yum.log

ファイルのパーミッションが「---x-wx-wT」という見たこともないものになっており、ユーザ名も所有者名も得体のしれない変な数字になっている。

ファイルの容量は、「7.5E」となっているが、この大文字のEは、エクサバイトのことだろうか。

1ギガバイト（1GB）の1000倍→1テラバイト（1TB）
1テラバイト（1TB））の1000倍→1ペタバイト（1PB）
1ペタバイト（1PB）の1000倍→1エクサバイト（1EB）

で考えると、すごい容量だが、このLinuxマシンのハードディスクは1テラバイト（1TB）にすら到達していないので、「7.5E」と表示されていても、本当に「7.5エクサバイト（7.5EB）」もの容量がある、ということはありえない。

ファイルの更新日は、1911年3月27日（Mar 27 1911）になっている。100年前・・・ね。

Linuxで、ファイルのパーミッション、所有者、容量、更新日などが変なものになっている場合、ファイルシステムが壊れている可能性がある。

上記の例を確認したLinuxマシンの場合、dmesgコマンドを叩くと、

EXT3-fs error (device hda3): ext3_readdir: directory #9157376 contains a hole at offset 1958699008
attempt to access beyond end of devic

といったエラーが大量に出ていた。

shutdown -r nowコマンドで、Linuxを再起動しようと試みると、正常起動できず、メンテナンスモードに入ってしまった。fsck -yコマンドにより、ファイルシステムの修復を試みると、運よく成功した。

※fsckは、失敗することもあり、失敗したら、二度と起動できなくなる、という恐ろしいこともありえるので（かつてそうなったことがある）、実行する際には注意と勇気と運が必要。

fsckでファイルシステム修復後、Linuxの起動に成功した後で、

/var/log/yum.log

のパーミッション等を確認しようとすると、このファイルそのものが消失していた。

/var/log/yum.logファイルが消失していたのは気になるところだが、

yum update -yコマンドを実行すると、無事にyum updateが成功したので良かった。

今後もCentOS5でのyum update実行時に「Cannot open logfile //var/log/yum.log」などのエラーでyum updateが失敗したら、

をしようと思った。