(FreeBSD) fsck_y_enable="YES"

FreeBSDだけではなく、Unix系OSでは、正しいシャットダウン処理が行われなかった後にOSを起動すると（リセットボタンを押したり、電源ボタンで電源を切ったりした後）、fsckで、ファイルシステムのチェックが行われます。

そういえば昔のSunOSやNEWS OSは、起動時は、とにかく毎回fsckしてたな・・・大容量のディスクがついてると、30分くらいかかってたっけ。大容量といっても数百MB程度だったけど。

ほとんどの場合は、fsckが済んだ後、OSの起動処理がつづきます。

ちなみに、fsckは時間がかかりますから、今のFreeBSDの場合、fsckには、background modeというのがあって、もしも可能ならば、fsckを後回しにして、先にOSの起動処理を済ませてしまって、ユーザーがログインできるようにしておいてから、fsckする、っていうことになってます。

よくわかってないのですが、たぶんルートパーティションはbackground modeが不可能みたいで、fsckが必要なときは、かならずfsckが実行されるみたいです。そのとき、エラーがファイルシステムで見つかった場合（軽微なエラーは自動修復してしまうみたい）、ユーザーに「どうする？なんとかして。」みたいなメッセージを表示して、fsckが止まり、OSの起動処理も、そこで停止します。

たいていの場合、「fsck -y」というコマンドを実行してやれば、ファイルシステムは正常になります。・・・というか、私は、「fsck -y」以外、どうやって修復していいのか知らないし（fsdbというコマンドがあるらしい）、fsck -yで修復できなかった、ということもないです。忘れてるだけかもしれないけど、もしそんなことがあれば、重要なファイルだけコピーして、newfsしちゃうかもしれません。

さてさて、このOS自動起動の失敗は、普通は、「あー、fsckで止まっちゃった」くらいのことですが、遠くにあるマシンで、これが起きてしまうと困ります。だれかに電話してなんとかして、と頼むとかしないといけません。

実は、FreeBSDの場合、/etc/rc.confで、

fsck_y_enable="YES"

と書いておくと、「fsck -y」で実行してくれるようになり、自動的に修復してくれるみたいです。
これ、けっこう前からある機能らしいのですが、私はつい最近、自動的にfsckしてくれる機能ってないのかな～と探していて、見つけました。

デフォルトでは、"NO"が指定されているので、ユーザーの指示をあおぐことになっています。

とりあえず、FreeBSDマシン全部、fsck_y_enable="YES"にしちゃいました。

softupdateは、深刻なエラーはめったにでない、ってことになっているので、大丈夫だとは思いますが・・・

☆

ネットワーク経由で、マシンの電源オンオフができたり、BIOSを設定したり、コンソールの操作だとか、OSのインストールまでできてしまうなど（PXEでnetwork bootさせるだけのこと？）、各種遠隔操作できるIPMIっていう規格があります。
残念ながら、IPMIは、サーバー系の、やや高価なマシンでしか使えないみたいです。SUPERMICROのマザーボードでは、けっこうIPMIがサポートされているらしいので、最近ちょっと気になっています。