先日、暫定対処したと思っていた本サーバが、今朝またOSのパニックで落ちていた。
ログが壊れたために直接の原因は断定できないが、今まで同様に、パッケージlibjson-c2の更新が切っ掛けではないかと推測した。それで、(前回はしなかったのだが、)Ubuntuのフォーラムに書かれていた対処(postinstというスクリプトを削除してlibjson-c2を最新版に更新する)をしてみたのだが、当然といえば当然ながら、やっぱり落ちた。更にそのスレッドを参考にして調べてみたら、libjson-c2の更新後にpostinst内で行われる、telinit uとかいう(初めて見る)コマンドを実行すると落ちることが分かった。
これに関連して謎だったのだが、僕のPCも同じUbuntuの系統(16 LTS)だけどlibjson-c2を更新しても落ちなかったのは、どうしてかtelinit uを実行しないからのようだ。その原因は、良く分からないのだが、僕のPCではupstartのセッションがある(PCではinitctl list-sessionsでセッションが出るが、サーバでは出ない)かららしい。それは僕のPCがデスクトップだからのようだ。
結局、Ubuntu 16 LTSのtelinitに問題があるようで、それは2014年に報告されたまま直っていないようだ。その後、何度かメジャーバージョンアップがあり、今回の問題に関係する仕組み(例: upstart)も大幅に変わったらしいので、放置・忘れられているのだろう。確かに古いけど、サポート期間内なのだから対応して欲しいとは思うが、まあ、あっちもパワーは有限だから仕方ない(それに、無料で使わせてもらっている)。
それで、至急OSのバージョンアップをすることが必要なのは よーく分かったのだが、そうは言ってもなかなか大変で、やろうと思ってもコマンド一発とかですぐにできるものではないので、今は再び暫定対処することにした。具体的には、パッケージの更新後に(postinstスクリプトに)telinit uを実行するように書かれていても実行されないようにした。
まず、libjson-c2のpostinstスクリプトを変更してtelinit uを実行しないようにしてみたが、libjson-c2を更新するとそのスクリプトも上書きされるので駄目だった。次に、telinitコマンドを無効にすることを考えたが、これは他からも使われる(特に、システムの起動時にOSのランレベル(実行モード)を変えるために使われるそうなのでとても重要だ)ので、それ自体をなくすことはできないので、引数に"u"が指定された時は記録だけして何もしないようなスクリプト("fake-telinit.sh")を作り、それにすげ替えた。
試してみたら、見事に起動しなくなったｗｗｗ
寝ぼけていたのか、telinitをfake-telinit.shにすげ替える設定(sym-link)に誤りがあり、起動時にランレベルが変えられなくなり、それ以上進まず、何もできなくなってしまった。まさに「にっちもさっちも行かなく」なって、観念して再インストールの手順を調べたら、使っているVPS(仮想サーバ)には「アップロードしたISOファイルからインストールする」という大変有能な機能があったので、それでUbuntuのインストーラ−を起動し、OSの修復モード(Rescue mode, Windowsのセーフモードのようなもの)で起動し、設定の誤りを修正して、どうにか再インストールせずに起動するようになった。以下はVPSの仮想コンソールの画面のキャプチャである。仮想コンソール(ブラウザで動く)がそれなりに使えたのも、大変助かった。。。
-
- Ubuntuのインストーラーで修復モード(Rescue a broken system)で起動する。
-
- 修復作業用shellを起動する。
-
- Shellが動き、修復作業ができるようになった!
落ちたのが分かってから直るまでに2時間くらい掛かって、心身共に大変疲れて今日の予定が吹っ飛んだ。
OS更新の代わりの対策は、今のサーバのOSでも動く新しいtelinitを探してインストールすることだが、探すのが大変だし(あるかどうかも不明)確認も面倒なので、保留している。
なお、パッケージ更新後にtelinit uの実行が必要なのにされないままだと、更新したパッケージが反映されないので、メールで通知するようにした。それが来たら手で再起動すれば良い(もちろん、理論的には自動で再起動するようにもできるが、とんでもないことになる場合があるので、しないｗ)。
僕のデスクトップPCは自動再起動しない設定で似たようなことをやっているから、結局、サーバの更新後に自動再起動する設定を止めればうまく行くのかも知れないが、今回は再起動している訳ではなく、telinit uで済ませようとしているので駄目な気もする。
最後に、今まで問題が起こらなかったことが謎だが、たまたまtelinit uを行うパッケージがなかったからかも知れない。あとは、プロバイダのメンテの結果、VPSの物理マシンが変わったためにtelinit uの挙動が変わったのかも知れない。
もし後者が原因なら、他のクラウド環境(例: AWS)でも現象が起こっているようなので、それ用に対処されたパッケージを探せば(あるのなら)直りそうだが、通常のPCでも起こっているようだから、仮想環境とは関係なく、ハード依存なのかも知れない。すると、やっぱり、「新しいtelinit」が要ることになる。
まあ、謎は多いようだ・・・
コメントを書く / Write a comment