2018/10/08から10/10の深夜までの二日間、このサーバーがダウンしていました。
直接の原因は起動ディスク上のOSが壊れたため。実は、ルートディスク上に部分的な故障が発生していることは時々ログに残ることがあるので、わかっていました。
Jul 7 22:53:22 tokyo kernel: (ada5:ata1:0:1:0): READ_DMA. ACB: c8 00 22 a6 1b 40 00 00 00 00 00 00 Jul 7 22:53:22 tokyo kernel: (ada5:ata1:0:1:0): CAM status: ATA Status Error Jul 7 22:53:22 tokyo kernel: (ada5:ata1:0:1:0): ATA status: 51 (DRDY SERV ERR), error: 40 (UNC ) Jul 7 22:53:22 tokyo kernel: (ada5:ata1:0:1:0): RES: 51 40 cc a6 1b 00 00 00 00 57 00 Jul 7 22:53:22 tokyo kernel: (ada5:ata1:0:1:0): Retrying command Jul 7 22:53:24 tokyo kernel: (ada5:ata1:0:1:0): READ_DMA. ACB: c8 00 22 a6 1b 40 00 00 00 00 00 00 Jul 7 22:53:24 tokyo kernel: (ada5:ata1:0:1:0): CAM status: ATA Status Error Jul 7 22:53:24 tokyo kernel: (ada5:ata1:0:1:0): ATA status: 51 (DRDY SERV ERR), error: 40 (UNC ) Jul 7 22:53:24 tokyo kernel: (ada5:ata1:0:1:0): RES: 51 40 cc a6 1b 00 00 00 00 57 00 Jul 7 22:53:24 tokyo kernel: (ada5:ata1:0:1:0): Retrying command Jul 7 22:53:26 tokyo kernel: (ada5:ata1:0:1:0): READ_DMA. ACB: c8 00 22 a6 1b 40 00 00 00 00 00 00 Jul 7 22:53:26 tokyo kernel: (ada5:ata1:0:1:0): CAM status: ATA Status Error Jul 7 22:53:26 tokyo kernel: (ada5:ata1:0:1:0): ATA status: 51 (DRDY SERV ERR), error: 40 (UNC ) Jul 7 22:53:26 tokyo kernel: (ada5:ata1:0:1:0): RES: 51 40 cc a6 1b 00 00 00 00 57 00 Jul 7 22:53:26 tokyo kernel: (ada5:ata1:0:1:0): Retrying command Jul 7 22:53:28 tokyo kernel: (ada5:ata1:0:1:0): READ_DMA. ACB: c8 00 22 a6 1b 40 00 00 00 00 00 00 Jul 7 22:53:28 tokyo kernel: (ada5:ata1:0:1:0): CAM status: ATA Status Error Jul 7 22:53:28 tokyo kernel: (ada5:ata1:0:1:0): ATA status: 51 (DRDY SERV ERR), error: 40 (UNC )
壊れつつあることはわかっていたものの、ルートディスクの故障はHDDの交換が必要になります。当然サーバーを停止してメンテナンスしないといけません。このサーバーは複数HDDでサーバーパーティションを構築しており、仮にルートディスク上の故障部分が広がったとしてもOSが死ぬだけで、Webサーバーのデータとか、メールが消えてしまうとか、そういう障害につながりません。ルートHDD上には /boot, /kernel, /bin と /etc くらいしかなく、カスタマイズされたファイルがあるのは /etcくらい。 OSなんて、もう一度インストールすればいいだけですからね。ついでにバージョンアップしてもいい。必要になるのは時間だけ。
それでも電子メールが不達になったり、ドメインが消滅するような長期間ダウンするのは困ります。何よりラジコの自動録音が止まってしまうと、番組ダウンロードをラジコタイムフリーが有効な1週間以内に手動でしないとまずい。
対策しなくちゃいけないとは思いながらも、サーバーを止めてHDD交換作業をするのは、OSを11系に上げる時でいいかな〜って思っていました。ルートHDDは、1.2GBの Bigfoot だし。
正確には、HDDを交換して修理するのと、別の新しいハードウェアに移行する2本立てで考えていました。可能ならスティックPCをサーバーにしたいところだったんですが、OSからSDメモリスロットのSDメモリにアクセス出来ないため、アクセスできるOSがリリースされるのを待っていたところ、HDD故障に間に合わず。
パッケージメンテナンスせずに運用していれば恐らく今も動き続けていたと思います。
きっかけは、Webログ解析ツールがlibpngに関してエラーを吐くようになってしまったこと。このエラーに関しては、苦労しましたが解決したのでひと安心。原因は、パッチレベルがより新しいOSでないとログ解析ツールが使用するライブラリが対応しておらずコアダンプして落ちるようになったことでした。
次にRadikoの録音をffmpegで変換しようとして、再度共有ライブラリが使えないというエラーが発生。
ffmpegの4系は、私のPCでは core dump してしまいます。そのため 3.4系を使用中。
> ffmpeg -h Shared object "libx265.so.146" not found, required by "libavcodec.so.57"
インストール済みパッケージをメンテナンスしたところ、ffmpegとの依存関係がくずれ、上記エラーで起動しなくなってしまった！
ffmpeg は、ラジコ録音のため毎日使用しており、これが動かないとラジコを録音出来ない！私にとっては結構重要。
エラーとなるライブラリの新しいバージョンを古いバージョンにリネームしてシンボリックリンクを張ってみましたが今回は効果無し。
問題切り分けのため、パッチレベルが上位のFreeBSD10.3 と ffmpeg3.4系の組み合わせで動いている別のサーバーで試したところ、ffmpegがエラーにならないことを発見し、このサーバーもパッチレベルを上げればいいのでは？と思いつきました。
ということは、このサーバーの OSをFreeBSD10.3 p20から 10.3 p24 へ上げればいいのでは？と思いつきました。で、freebsd-update fetch install コマンドで最終パッチレベル p24 へ上げてOSをリブートしたところ、kernel が見つからずOSが起動しなくなったという訳。
運悪くというか、必然というか新しいカーネルが Bad Sectorの上に置かれてしまったようです。古い kernel.old から起動しようとしたものの、これも駄目。
やむを得ず、電源を落として翌日HDDを交換に決定。そして、回復まで丸二日を要することになります。
幸い、旧サーバーが残っていて、OSがFreeBSD 10.3なのでルートディスクをダンプコピーすることにしました。
- まず、起動不能になったHDDを取り外し、別のFreeBSDサーバーと接続。/etc と /root をバックアップします。
- 次に、新しいHDDを準備。2代前のサーバーで使っていた10GBのHDDが保管されていたので、これを使用することにし、旧サーバーへ接続してフォーマットとファイルシステムを作り直し。
余談ですが、壊れたHDDはGPTパーティションにしていましたが、小容量HDDではGPTにそれほどメリットはないと感じ、今回のファイルシステムはMBRにしました。スワップを500MBほど確保し、残り9GBくらいをファイルシステムに設定。 - dump, restore でファイルシステムを丸ごとコピー。
dump -0aLC 32 -f - / | ( cd /mnt/root && restore -rf -)
パーティションサイズが同一なら dd コマンドを使うことも出来ますが、異なるので dump/restore で実行。大量のコンテンツを含む /var やバックアップから戻す /etc なんかは中身を削除。
5GBくらいのファイルシステムだったので、1時間くらい掛かりましたが /var の中身を消したら 400MB でした。殆どがキャッシュデータでした。 - /etc/fstab 内の交換したroot パーティションデバイスファイル名を更新。
- Bigfoot を、取り外したIDEケーブルに HDDを接続し、ケースにマウント。これで作業は完了。
のはずでした。
ところが、元のサーバーへHDDを戻して起動すると、なぜかファイルシステムの段階で mountroot> プロンプトが出て来てストップ。
そこで、
ufs:/dev/ada5a
とやっても、先に進めない！
? でマウント可能なパーティション名を表示して、そこに表示される ada5 を ufs:/dev/ada5 とすると、Panic です。勘弁してくれれ。平日作業なので、ここら辺でギブアップ。ダウン翌日復活ならず。
翌日昼間に回復方法をいろいろ検討。
- OS再インストール
- 新HDDを fsck
- さらに、HDDを交換して、dd によるOSコピーのやり直し
夜になり、マウントできないHDDを旧サーバーに接続し fsck してみるものの問題なし。
せっかくHDDをつないだので、既存のHDDを切り離し、テストでコピーした新HDDの fstab を編集し、起動してみる。
不思議なことにこれだと、OS起動直前まで行く。/usr が無いので、途中で止まりますけどHDDに問題はなさそう。
何が違う？
よくよく見てみると、IDEケーブルが40pinと高密度IDE 80pinの違いがありました。
Bigfoot はATA33なので、現行サーバーでは柔らかい40pin フラットIDEケーブルを使っていました。新しいHDDは ATA100。普通は高密度IDEケーブルを使用しますが、下位互換なのでATA33ケーブルを使ってもATA33互換でつながるはずだと思っていました。まさか、起動中 mountroot に落ちるのはATAケーブルのせい？
確かめるため、80pin ATAケーブルを探して、ATA33ケーブルと差し替えてみると、なんとイメージコピーしたHDDから無事に起動しました。
遅いインタフェース用ケーブルに、より高速なATA100 HDDを接続すると、転送速度は無駄になるものの ATA33 モードで接続されるものとばかり思っていましたが、OSはHDDの情報を解析してATA66以上で接続しようとするようです。これで丸一日悩んでいたかと思うと悔しいですが、イメージコピーのやり直しやOS再インストールを行う前に原因がわかったのは良かったです。
さて、本来の目的、ffmpeg が動かない件は、最新の FreeBSD10.3 p24 に上げて解決したかというと、下記のように、症状に変化無し。
> ffmpeg -v Shared object "libx265.so.146" not found, required by "libavcodec.so.57"
もう一台の ffmpegインストール済み サーバーでエラーが出ないのはなぜ？と思いながらも復旧を優先させたため、原因究明はまだ出来ておりません。