先日書いた謎の二つ目、「ブログサーバーが突然落ちた・・・」も解けた感じだ。

書いてからは落ちていなかったのだが、今日、PHPを更新しようとしたら、以下のようなエラーになり、メッセージに従ってdpkgコマンドを実行したら、パニックで落ちた(「え? 言うとおりにやったんですが・・・」って感じだったw)。

E: dpkg was interrupted, you must manually run 'sudo dpkg --configure -a' to correct the problem.

それで、OSのエラーの出るサーバの仮想コンソールを見ながら再度同じコマンドを実行したら、

Setting up libjson-c2:amd64 (0.11-4ubuntu2.1)

と出て落ちた。どうも、libjson-c2というパッケージの更新が駄目なようだ。それで、試しにパッケージ情報の更新(apt-get update)をしてみたら別のエラーになった。検索すると、dpkgやaptのロックファイルを削除すればいいとのことだったが、それでもエラーになった。他のロックファイルを探して削除したら、パッケージの更新はできたが、libjson-c2の再インストールはPHPと同様のエラーになり、書かれているとおりにdpkgを実行したら、やっぱりパニックで落ちた。

どうもOS自体がおかしいようなので、調べてみることにした。

まずは、dpkg -Vというコマンド(今日知った)で各パッケージの状態を見てみたら、やっぱり、libjson-c2とlibjson0の状態が駄目っぽかった。

$ dpkg -V
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad)
:
iF libjson-c2:amd64 0.11-4ubuntu2.1 amd64 JSON manipulation library - shared library
iF libjson-c2:i386 0.11-4ubuntu2.1 i386 JSON manipulation library - shared library
iU libjson0:i386 0.11-4ubuntu2.1 i386 JSON manipulation library (transitional package)
:

そこで、それらのファイル(ライブラリ)が壊れたかと思い、メンテの前(5/11)にバックアップされていたもの※と比較したら、下記のように中身が違っていた。

$ md5sum {/,}lib/x86_64-linux-gnu/libjson-c.so.2.0.0
db908af9fa464b97b899e0b941019655 /lib/x86_64-linux-gnu/libjson-c.so.2.0.0
215d2780de0df769cb336679c06be7cb lib/x86_64-linux-gnu/libjson-c.so.2.0.0

※定期的に自動でクラウドにバックアップしていたのが役に立った!!

ログ(先日落ちたせいで後半が壊れている)を見る限り、メンテ前後にこれらは更新されていないので、(理由は不明だが)破損したようだ。なお、i386版も同様に違っていた。また、libjson0のファイルは無関係だった。

そこで、破損しているlibjson-c2のライブラリ2個をバックアップされていたものに交換して再起動し、パニックの起こったコマンド(sudo dpkg --configure -a)を実行したら、嘘のように成功した。更に、パッケージ情報の更新も成功し、PHPの更新すらスルッと行った。

結局、サーバが落ちた原因や過程を推測すると、以下のようになる。

  • メンテの頃(?)に、なぜかパッケージlibjson-c2内のライブラリが壊れた。
    • もしかしたら、メンテの終わる時刻の数分前に起動したために、中途半端な状態になったのかも知れない。
    • あるいは、メンテ後の起動直後にlibjson-c2の更新が行われ、システムが不安定だったので、成功したとされつつも、実は失敗していたのかも知れない。
    • あるいは、メンテ(物理サーバの移動)でのデータ移動がうまく行かなかったのかも知れない。
    • あるいは、メンテ前から別の問題で壊れていたのかも知れない。
      • 例: 物理サーバの劣化でディスクのその箇所が壊れた??
    • 実は、サーバ内で壊れたのでなく、元々(パッケージの提供元で)壊れていたか、自動更新時のダウンロード時に壊れたか、壊れはしなかったが、(なぜか)このサーバに合わない版がインストールされた。: この場合、再発する可能性が高い。 → (5/29 7:37) これが原因だった。壊れていたのでなくパッケージにバグがあったようだ。そして再発した。。。
  • libjson-c2は重要なので、壊れた状態ではパッケージ操作が失敗したり、OS(カーネル)がパニックで落ちるなどの問題が起こるのだろう。
  • 最初に落ちた時は、偶然、自動更新が行われて、今回パニックの起こったコマンドと同様の状況になって落ちたのではないか。

ライブラリが壊れた理由が分からず怖いが、他は問題なく動いているので、データ移動の失敗とは考えられない。すると、メンテ後の最初の起動が変な感じだったので、起動がちょっと早かったのかも知れないし、プロバイダが交換するくらいなので、ハード(HDD)の不調はありそうだ(少なくとも、僕が使ってから(推定約十年)は24時間連続稼働している)。それから、壊れた・おかしなパッケージが来た可能性は少ない。インストールの前に、チェックサムなどで正当性がチェックされるはず(未確認)だからだ。ただ、提供元の不手際で違うものが来た可能性は0ではない。駄目だったファイルを詳しく調べれば何が悪かったか分かるが、ちょっと面倒だw

謎(ライブラリが壊れた理由)はまだ残っているが、ひとまず、元の謎が解けたし、いつも「意味あるんかいなー?」と思って居たw、定期自動バックアップが威力を発揮したのも良かった^^ 本当に、コマンド一個で過去のファイルが取得できた(バックアップを繰り返しても、数か月前までの履歴が残っているので、今回、壊れたものがバックアップされていたとしても、それ以前のものを見つければ、壊れる前のファイルが得られる)ので、楽ちんだったし安心だった。

だから、履歴が残るバックアップを皆さんに勧めたいが、簡単に使えて安いものはなかなかない気がするなぁ・・・ いや、実際にはWindowsならあるんかな?

 

(2020/5/29 7:37, 8:12) 今朝、パッケージの自動更新時に、再び同じ現象で落ちてしまった。再びlibjson-c2が更新されたためのようだ。とりあえず、libjson-c2を元に戻し、以後はlibjson-c2とそれに依存するlibjson0が更新されないようにした。以下に、更新しないようにするコマンド例を書く。

echo libjson-c2 hold | sudo dpkg --set-selections

調べたら既知の問題だった。そこには「libjson-c2を0.11-4ubuntu2.5に更新すれば直る」(Chris Newcomer (cnewcomer), 2020-05-15)とあったが、今回は、libjson-c2を0.11-4ubuntu2.6に更新しようとして落ちたので、それも違う気がする。いや、一旦ubuntu2.5に更新すれば良かったのかも知れない。もう少し試してみる。

いずれにしてもASAPでOSを更新すべきなのだが、どうにも面倒だ・・・

(2020/6/2 13:20) その後再発し、直接の原因が分かったので暫定対処をした。telinitコマンドに未解決の問題があるようだ。

 

PS. これはクラッキングとかマルウェアの影響とかじゃないと思うが、ちょっと怖いな・・・ とりあえず ここに記録して、忘れないようにしよう(でも、きっと忘れるがw)。

PS2. 自慢する気はないが、これ、普通の人だったら原因が分からずに、「なぜか時々落ちる・・・」になると思うが、まったく「あなたならどうする」状態だw やっぱり、主要なところをバックアップから戻すとか再インストールとかなのだろうか。あるいは、なんか分からず大嫌いになって、「クソが!」とか言って新しいマシン・OSに換える??

PS3. 最後にちょっと言いたいのは、この世の中に「謎」は余りないってことだ。大抵は、論理的に調べれば原因が分かるはずだ。ただ、調べることが難しい場合はある。でも、すぐに「相性がー」とか「たまたま」とか「様子を見ましょう」とか言う連中が一番信用できない。でも、真の謎は確かにある。そんな気はする。

PS4. 検索していたら、この問題は意外なところ(日本医師会: 障害報告◆日レセ オンプレ版 起動不可, 2020-05-15)にも波及していて可哀想になった・・・ (2020/5/29 7:37)

  •   0
  •   0

コメントを書く / Write a comment

名前 / Name    

メール / Mail 

URL