FreeBSDのlogin(1)が壊れてログインできない

これは、とある大規模バックエンドシステムの話です。

FreeBSDマシンを32台構成や128台構成にして組まれている大きなバックエンドシステムがあります。何百台もあって、アラートが絶えずやってきます。ストレージが壊れたりと故障が多く筐体を3ヶ月に30台もリプレイスすることがあります。

アラートのメールに起こされて、システムの様子を見ようとすると普通にsshでログインできませんでした。仕方なく、運用担当者は、コンソールからログインを試みます。どうやら、障害が発生し、自動的にマシン(かオペレーティングシステム)がリブートしてしまったようです。そのままファイルシステムがちゃんとマウントできず、シングルユーザーモードで起動していました。エラーメッセージに従い、とりあえず、fsckを実行しました。

その後で、fsckが終わったあとにC-dをして、マルチユーザを上げました。そうすると、今度は、起動したももの、ちゃんとシステムが起動していないことが、アラートメールで解りました。

何がおかしいのか、調査するために FreeBSDに sshを試みますが、/usr/bin/login が実行形式(ELF)じゃないよとgettyに言われるようです。どうやら、障害時にHDDのデータが壊れたと思われます。こうなってしまうと、コンソールからもログインすることができません。

ssh backendsystem sh

でshは起動できますが、

ssh backendsystem csh

とかすると、core dump してしまったりしました。

ssh backendsystem /usr/bin/file /usr/bin/login

とかすると、意味不明(初めて見たタイプ)なファイルのタイプであるとfileコマンドは言い、要するにELFじゃない、ということでした。

ファイルシステムがおかしくなってしまったのか、ハードウェアやストレージがおかしくなってしまったのか、原因が特定しにくい状況ですが、とりあえず、オペレーティングシステムの入れ直しをして様子を見ることになりました。ちなみにストレージはRAID5が組んであります。

ヘタに動いてしまっているばっかり、監視設定は機能してしまっていて、中で必要なプロセスや処理ができないために、アラートメールはひたすら送信され続けて、でも、ログインできないから、アラートが止められないという非常に辛い状況に陥っていました。サーバ自体は、データセンターで自分では簡単に止められない場所にあり、完全にお手上げでした。

こういう自体に陥ってしまうとリモート環境は辛いですね。
システムの運用は大変です。特に台数があると、さらに大変です。
自分のローカルホストだけでも、色々面倒があるのに、ですよね。

---