安定してた共有サーバーダウン

昨日たまたま sshで操作ついでに思い立ち、通常のセキュリティアップデートのつもりで久し振りのコマンド操作後にリブートしたら、安定して運用中の Raspberry Pi 1B の共有サーバーが死にました。

学習しないで同じ轍を踏むとは自分でも悲しいです。最新版の Raspbian は、要注意だという事を改めて再認識させられました。

他にも Raspberry Pi のサーバーが稼働していますが、少し前の Raspbian をセットアップしたサーバーなので、単純にセキュリティアップデートだけが行われたらしく、そのままに稼働しています。

以前のメモを頼りに復活させますが、最新のOSで作って良いのか悩みます。

頭を冷やして少し考えてから判断したいと思います。

(再)ラズパイ3のセットアップ 〜完全な挫折です

セットアップ途中での挫折で、最初からの仕切り直しになりました。

勝手にシステムのアップデートが行われて動作不能になるラズパイ3ですが、再起のため最新の Raspbian OSを入れるところからのセットアップの途中で、Sambaの設定でも変な動きをして共有が正常に動作させられなかったり、WebサーバーのApache2が変な動きをしたり、リモートでのメンテナンスでは必須のsshの設定でも、意図して設定しているはずの動きとは異なるような認証動作が行われていました。

究極の問題は、apt コマンドで、最新のモジュールに入れ替えたり、新しいプログラムをインストールできない問題に直面してしまい、色々と調べたり回避策を模索していて時間が取れなくなって仕方なくしばらく中断していました。

changelog を読んでいます... 完了
パッケージからテンプレートを展開しています: 100%
パッケージを事前設定しています ...
dpkg: unrecoverable fatal error, aborting:
パッケージ 'vim-runtime' のファイル一覧ファイルに最後の改行がありません
E: Sub-process /usr/bin/dpkg returned an error code (2)

 

やっと触れる時間ができたので、google検索をしてみると、同様の内容と思われる記事が多数アップされています。⇒日本語で対策を教えてくれているサイト

今回は、単純に昔からの方法での dd コマンドでイメージコピーしただけなのですが、初めて見たようなオプション “conv=fsync” を追加してコピーしないと意図しない結果になるようです。最近公開されている Raspbian OS についてらしいです。

今のままの不安定な状態から個別にリカバリーしても気が遠くなる作業が続いて、収束の見通しが建てられないようなので、仕方ないので最新の OS ダウンロードからやり直すことにします。

今回はセットアップ途中での挫折です。仕切り直しですね、完全な玉砕です。

勝手に壊される raspbian

Raspberry pi は、Linuxシステムが壊れてしまう不安定なシステムとの認識を発売当初から持っています。最近では一般にSDとの相性問題と言われているような、SDに問題が有りそうだとのメーカー名と製品をリストにした情報が公開されています。

当初は問題を切り分けできる情報も少なく、ある程度実用になる設定を施した頃になると、必ず水を挿すようにシステム障害になっていて、再びやり直しとなって時間ばっかり掛かるだけで使えませんでした。

そんなわけで、Raspberry pi は、ブートの初期には必ず SD や microSD を必要とするので、その後にマウントされるルートシステム以降の処理をUSBハードディスクに移行する方法で安定したシステムとして稼働させていました。

ルートシステムをハードディスクに移行してからは、Raspberry pi 1 B+ や Rasberry pi 2 B を純粋なサーバーとして利用していましたが、特に問題なく稼働していて、時々手動でシステムの update を実行していました。

でも何故か壊れる Raspberry pi 3 B です。こちらはデスクトップ環境で構築していて、特には利用していませんでしたが、付属として3.5インチLCDディスプレイとタッチパネルが装着されています。そして家屋内の共有ディスクとして利用して、データのバックアップシステムとしても利用していた重要なシステムでした。

問題のシステムが動作不能になったのは、ハードディスク障害等の明確なものを除くと、設置から今までの1年足らずで大きく数えて 2回あります。2回共に自動でシステム更新されたらしく、sshでネットログインが出来ず、再起動しても期待した立上げが行われませんでした。

ただし、1度目は大きく変更されていたわけではないようで、ルートファイルシステムとしてのUSBディスクが無効に変更されていたのが 原因で、ほぼその修正だけで立上げが行えました。ただし、デスクトップ画面は別物として一新して見た目は大きく変わっていました。

2度目の今回は、システムが勝手に大きく更新されているようで、前回のように簡単に修復が出来ませんでした。Raspberry pi は、頻繁にシステム構成が変わっているようなので、安定稼働を期待するサーバーの運用には向いていないのかと思ってしまいます。

何故か時々壊れる(壊される?) Raspberry pi 3 ですが、正常に運用していたシステムが動作不能になると、今までに色々とインストールしているモジュールやら設定が問題になります。

微かな期待として、何とかリカバリして上手く復旧が出来て、そのまま利用の継続ができればベストなのですが、今回はping での反応はしていたものの ssh 接続は出来ず、共有ディスクとしてのサービスも機能してなくて、ログ情報を定期的にメールとして送る機能も動作していませんでした。

電源OFF/ONによる再起動を試みたのですが、正常に立上がらないようで、仕方なくモニタ用にテレビをHDMI接続し、キーボードとマウスを繋いでの復旧を試みたのですが、見慣れない画面が出るだけで、Linuxで一般的な立上げバナーも皆無です。システムが大きく変更になったようでした。

ここまでの状況からは、システムの再インストールが必要な状況のようですが、そこで同じ程度の環境に戻すには、色々なモジュールのインストールや設定を再び施す必要があります。システムが正常に動作しているなら、dpkg -l のコマンドでインストールされたモジュールのリストが出るようです。しかし、再インストールしたら以前の情報は消去してしまいます。

立上げ不能のルートシステムを、別に立上げできる正常なシステムを利用して、そこに繋いで残された情報から調べる以外に無く、操作方法をネットの情報から調べ、 apt-get で操作した場合に残されるログから、インストール時に記録された情報を抽出することにします。

記録ファイルは、/var/log/dpkg…. で始まるファイル名で残されているようです。過去のものは圧縮されているようです。

/var/log/dpkg.log
/var/log/dpkg.log.1
/var/log/dpkg.log.xx.gz  … xx 部分が数字の圧縮ファイル

ざっとログ内容を見てみると、インストールしたモジュール名の抽出には、 grep -e  ‘ install ‘ が有効と思われます。指定する文字列は、 ‘install’ の両端を半角の空白で挟んで指定します。

再インストールと修復では、地道に稼働していた状態の最後の dpkg.log から突き合わせて元の状態に近づけようと考えてます。

まずは、ラズパイ3 の再インストールから作業を始めます。なんと1年前にも同様の書き込みがありました。

システム障害発生(2016-08-25 15:45頃)

本日(2016-08-25 15:45頃)、公開サーバーが障害でサービスに支障が出ていたので、再起動を行いました。

未だに原因は分かっていません。ssh のリモートログインも出来なくなっているので、動作状況も残されたシステムログ程度しか無いのが現状です。しばらくは再起動後の様子を見ているだけで、有効な対策が打てそうにありません。

いつでも交換ができるように、代替機を考えて、現在はラズパイ3を設定している最中ですが、できるだけ急いで仕上げておく以外に方法が無さそうです。

今後もシステム停止が頻繁に発生しそうです。

ご迷惑をお掛けしますが、宜しくお願いします。

 

システム障害発生、頻度が高いですね

公開しているサーバーで、本日(2016.07.05)の午前中にシステム障害が発生しました。システムの最立ち上げで復旧しています。

過去の発生も含めて、原因の特定には至っておりません。Webに訪れていただいている皆様には大変ご迷惑をお掛けしています。

自分でリモート操作中に理解できない不穏な動きを確認して、状況を調べていましたが、Webサーバーとしての機能停止やSSH接続ができない状況でした。

当初は判断がつかずに、勘違いかなと考えていて復旧が遅れたことをお詫びいたします。携帯メールを確認すると以前に仕掛けた障害検出メールが多数送られてきていました。

原因もわからず障害頻度も高くて心配ですが、様子見で経過を見守りたいと思います。

以上

公開サーバーの監視とエラーメール

公開サーバー(Pogoplug E02)の停止を監視する別のサーバーとして、ARMのサーバー3台にスクリプトを組み込み監視させてみました。監視間隔を5分として常時監視させる方法です。

実際に公開サーバーが障害になった時に、問題無くエラーメールが届くのかは起こってみないとわかりませんが、確認テストとしてはLANケーブルを抜いて確かめてみました。メール先にしていた携帯メールには期待したメールが届くのを確認できました。

一応、エラーメールを送信させることは可能のようです。ただ少し気になるのは、サーバーが 3台で監視スクリプトが各2種なので、計6メールが届くことを期待したのに 5メールだけ届きました。

何故か届かなかった一件のメールは、Webのhttpリクエスト確認エラーメールでした。一応監視側サーバーのメールログを確認するとエラーメールは作成されて転送されているようでした。

複数サーバーで監視させているので、1つ2つ届かなくても特に大きな問題でもないですね、あまり気にしないことにします。

それより監視方法を1種類増やし、sshログインの確認チェックを追加することにしました。方法は単純に接続して、簡単なコマンドを実行して終了するだけのもので、正常に接続できれば含まれるメッセージの文字列で成否を判定することにします。

実行するsshのスクリプトは次のようなものを作成しました。

#!/bin/bash

To='sunao_mita@.....'   # To: メール転送先
 T='sunao-mita.pgw.jp'
 test -z "$1" || T="$1"   # T: 監視するサーバー
 Su="## SSH Error <$T> ##"

rt=`
 ssh -4 -t -t "$T" <<EOF 2>&1
 pwd
 exit
 EOF
 `

ck=`echo "$rt" | grep -e "Connection .* closed\."`
 test -z "$ck" && ( echo "SSH Error <$T>." | mail -s "$Su" "$To" )
 exit 0

先に示した他の方法(ping/wget)と同じようなスクリプトで、sshのリモートログイン後に、pwdコマンド、そしてexit しています。簡単な短いコマンド列なのでヒアドキュメントで与えました。sshコマンドの標準エラー出力は、標準出力にまとめて( 2>&1 )取出して、接続後のメッセージの判定に利用しています。

監視を組み込んだのでしばらく様子見ですね。

サーバーからメール送信の難しさ

このWeb公開サーバー(Pogoplug E02)が、原因不明で時々クラッシュするようです。気付いて再起動すれば復旧しているのですが、それを知ることが出来なくて、ずっとわからないまま長期間の動作不能状態になってしまいます。

対策としては、動作を監視していて検知したらメールを飛ばすことで対応できると考えました。方法としては単純なので対策が簡単に出来ると思っていたのですが、やってみるとなかなか大変で、途中にハードルが沢山隠れています。

検知方法は、(1) ping 、 (2) wget の2種類で試作してみました。

(1) は、一般的な ICMP パケットを 5回送信し、相手からの応答を要求してロスがなければスルーして、ロスがあればメールを送信する方法です。

#!/bin/bash

To='sunao_mita@.....'  # To: メール転送先
 T='sunao-mita.pgw.jp'
 test -z "$1" || T="$1"  # T: 監視するサーバー
 Su="## Ping Error <$T> ##"

ck=`ping -c 5 $T | grep ' 0% packet loss'`
 test -z "$ck" && ( echo "Ping Error <$T>." | mail -s "$Su" "$To" )
 exit 0

(2) は、単純にwgetコマンドで、httpリクエストを要求して取り出せれば正常と判断し、取り出せなければメールを送信する方法です。キャシュに残るデータで正常と判断されて検出できないことが有りそうで少し心配です。

#!/bin/bash

To='sunao_mita@.....'
 T='sunao-mita.pgw.jp'
 test -z "$1" || T="$1"
 Su="## HTTP Error http://$T/ ##"

`wget -q -O- http://$T/ >/dev/null`
 test "$?" -ne 0 && ( echo "HTTP Error http://$T/" | mail -s "$Su" "$To" )
 exit 0

実際にテストしてみるとメールが届かない、なぜ…

監視しているサーバーの postfix が、単純に監視される公開サーバーへエラーメールをリレーしているので、監視されるサーバーが異常となって、エラーメールが生成されてもリレーの機能も異常なわけで、メールが転送できずに届かないといった問題がありました。

昔は単純に@niftyのメールサーバーに転送すれば機能したのですが、スパムメールを大量に送りつける悪い人が多くなりいつの頃からかパスワードでの認証が必要になってしまいました。

正常にメールを送信できる公開サーバーの設定 /etc/postfix/main.cf を参考にして、監視サーバーからも生成したエラーメールを直接 @niftyにリレーできるように設定しました。

公開サーバーのLANケーブルを抜いてテストしてみます。

Web公開サーバーの障害

Web公開サーバー(現在はPogoplug E02)が、異常でアクセスできない状況になっていました。詳細はまだわかりませんが、4/13 の10:54頃からはアクセスログの記録がなかったので、この頃からは完全にアクセス不能だったものと思われます。

再び子供から指摘されました。頻繁にシステム障害になるようなら、常時サーバーを監視する機能を組み込まないといけないですね。

今回も強制的に電源のOFF/ONで、システム再起動を行いました。  ⇒ 2016-04-13 / 20:10

様子見で継続稼働させておきます。

確認すると前回のダウンが 3/2 のようです。約40日で再発生ですね。ちょっと頻度が高いでね。 1月経っても何の対策もできていないわけで、情けないですね。

早めにラズパイ 2 を手に入れて、システム全体を載せ替えないといけないですね。

ここに立ち寄ってくれている皆様、申し訳ございませんでした。これからも時々起こると思われますが、少し時間を作って異常になっていることを短時間で知る方法を整備し、復旧を早くできるように対策しようと思います。

公開サーバーがダウン

久し振りになるblogの更新です。

日常の家事に追われてバックログが蓄積の一途に、時間が欲しい。

そんなこんなで公開サーバー(このblogや写真の蓄積用)の相手をしないで掘ったら貸したまま放置してたのですが、サーバーに仕事を放棄されてしまいました。

再立ち上げしてログをざっと見たのですが、原因は分かりませんでした。システムログは3月2日の朝11時頃が最後で、気が付いたのが3日の夜11時頃なので、丸1日半停止していたようです。時々訪れてくれる貴重な方々にはご迷惑をお掛けしました。

停止した原因も解明出来ていませんが、SSHのリモートでのログインの操作も出来ず、一番原始的な電源コードを抜いて、再度差し込む基本的な方法で復旧しました。

昔のUNIXを知る身には、電源コードが抜けてファイルシステムの復旧に半日や1日掛かった記憶が嘘のようで、なんと軽快に復旧してしまうのだろうと思い一安心しました。

外から保守出来るように、何の細工もなく標準の22番ポートは開けてあり、何時ものようにアタックしているログは記録されていますが、パスワード認証はさせてないのでそこに問題は無さそうですが、さて何が悪いのでしょう。

昨年の夏の前にセットアップして、ざっと半年は稼働していた訳なので、まずは良しとしましょう。ただ、不具合をもっと早く発見できる何らかの対策が必要だと痛感しました。

サーバーに問題が発生した頃に、実は子供からWi-Fiで利用しているゲーム機?の動作が何か繋がりにくいけど、ネットワーク機器を変えたのかと聞かれてました。

何でそんな分かりやすいサインを見落としていたのかと、確かにDHCPサーバーも屋内のDNSサーバーもそこに集約させていました。そういった管理的な仕事をしていた会社を去ってから早5年、今の頭は完全に錆びきっていますね。

時間を作って、別のサーバーから定期的に主要なポートの稼働チェックとping死活チェック、不具合検出時の自動報告メール機能を組み込まないと駄目ですね。

しばらく様子を見るしかなさそうです。このblogのサーバーでもありますので…