google-site-verification: google3bd66dd162ef54c7.html

Raspberry Piのメンテナンス

 うちではグリッドタイインバーター (GTI) の運転状態の監視Flight Radar24 (FR24) へのフィードのために Raspberry Pi (ラズベリーパイ)を24時間連続運転しています。FR24へのフィードは一旦止めたのですが、受信用ドングルを使った遊びも一段落したので再開しています。

▼Raspberry Pi
Raspberry Pi

 これが12月初め頃から調子がわるくなってしまったのでシステムのアップデートなどの対策を何度か行いました。どうやら症状は治まったようなので、自分用のメモを兼ねて、アップデート作業の内容やその後の効果の確認方法についてまとめておきます。

 時系列で何が起きていたかを知るには xively に記録しているGTIの運転状況を見るのが一番判りやすいです。

▼xively に記録されたGTIの運転状況 (直近1ケ月分)
xivelyのグラフ
 このグラフの見方は過去の記事を見て頂くとして、グラフが平坦になっているところがあります。これは何か不具合が発生して、データーの更新が行われなかったことを表わしています。

 不具合は4回発生していて、説明し易いように該当箇所に①から④まで番号を振りました。以下順に状況を説明していきます。

① この時はRaspberry Pi の運転が止まっていました。電源は入っていたのですが、Linuxが走っていませんでした。回りの配線を動かしたりしたので暴走してしまったのかも知れません。
 このラズパイは2年以上連続で動いているので、まさか落ちるとは思っていなくて、気付くのに2日以上かかっています。

 そこで再起動させて運転開始したかと思っていると、

② ここで停止しています。この時はOSは動いていましたが、なぜか xively への送信プロセスが止まっていました。こんなふうに止まったことは、これまでに一度も無かったので、怪しいのはフライトレーダー24のフィード用プログラムです。

 しょうがないなー、と思いながら再起動。ところが、

③ 約3時間後に止まっています。FR24へのフィードは正常に動いていますが、xively への送信だけ止まっています。

 こりゃFR24のフィード止めるか、とも思ったのですが、ラズパイのアップデートをずっとやってなかったのでまずはそちらをやってみることにしました。以下のコマンドでシステムをアップデート。
sudo apt-get update
sudo apt-get upgrade

 大量のアップデートがかかってかなりの時間がかかりましたが、無事終了です。このコマンドはこまめに実行した方がいいのですが、なにぶん普段は放ったからしのシステムなので、そうはいきません。

 これでリブートして再起動。うまく動いているので対策効果が出たと思っていたら、

④ ここで半日間止まっています。これまでと違うのは自動的に再開していることです。xively への送信プログラムは、ネットワークエラーなどでまれに止まることがありました。そこでLinuxのシェルスクリプトで監視し、もし止まっていたら再起動をかけるような仕掛けにしてあるのでこれは本来の動作です。④はおそらく xively 側が止まっていたのだと思います。

 xively への送信は運転状況のログをファイルに落とすようにしてあるので、その中身を真面目に見てみます。

▼ログの様子
エラーログ
 これでは訳が判らないので Excel に食わせてやります。

 そのためにまずはファイルをネットワークの共有フォルダにコピーします。うちのラズパイの共有フォルダは /media/usb0 で、ここに置いたファイルは外から見えるようになります。
cp abcd.out /media/usb0/abcd.out

 Excelで読みやすくするために Windows のFINDSTRコマンドで、年という文字が入っている行だけ抽出します。
FINDSTR /C:"年" abcd.out > abcd-x.csv
これでエラー発生日時の行だけ引っこ抜いたファイルが出来ます。なお、コマンドプロンプト画面をフォルダの深い階層まで移動させるのは大変です。そういう時はエクスプローラーでそのフォルダに移動しておいて、アドレスバーに CMD と入力してリターンキーを押すと、一発でその階層に行った状態でコマンド画面が開きます。

 まだゴミの文字がいっぱい入っているので、エディタの文字列置換で置き換えて、Excelの日付・時刻関数で読める書式に整形。最後に文字コードをshift-JISに変更して保存。

 あとは Excel で調べるのが楽ですが、とりあえずグラフにしてみました。

▼エラー発生時刻のマップ
エラー発生日時プロット
 横軸が時間軸(日時)で縦軸は24時間で表わした時刻。プロットした点はプログラム ( xively へのデーター転送プログラム) の再起動がかかったタイミングを表わしています。けっこうな頻度で再起動がかかっています。昔は一日に一回あるかどうかだったので、FR24のフィードプログラムの影響が出ているのだと思います。

 このグラフを見ると、昼間の方がプロットが多い(つまりよく止まっている)感じがします。これ、昼間は飛んでいる飛行機が多いので FR24 への通信料が増え、その影響で xively との通信失敗の頻度が上がるとも考えられます。

 ここで判るのは、①から③までの停止は再起動のプロセスが失敗していたということです。ただその原因は、良く判りません。③の停止の後でシステムのアップデートをやっていますが、それ以降は止まっていないようです。

 ④でプロットが連続しているのは、xively から応答が無かったのでプログラムが停止し、それをシェルスクリプトが2分間隔で検出して再起動をかけ続けているからです。

 とりあえず正しく動いているようなので、このまま運転継続したいと思います。apt-getでシステムを最新にした効果が出ているなら嬉しいのですが。

 それと、今気付いたのですが、昨日も xively の調子がおかしくなっていましたが、どうしたんでしょうね。IoTの旗手として注目されたこともある xively ですが、最近は調子悪いのかも。
関連記事

コメントの投稿

管理者にだけ表示を許可する

カレンダー
09 | 2017/10 | 11
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31 - - - -
プロフィール

ラジオペンチ

Author:ラジオペンチ
電子工作を中心としたブログです。たまに近所(東京都稲城市)の話題など。60過ぎて視力や器用さの衰えを感じつつ日々挑戦!
コメントを入れる時にメールアドレスの記入は不要です。なお、非公開コメントは受け付けていません。

記事が気に入ったらクリックを!
最新記事
カテゴリ
最新コメント
リンク
FC2カウンター
検索フォーム
月別アーカイブ
RSSリンクの表示
QRコード
QRコード