さて、計画停電（輪番停電）だが、最近行われない。気候に助けられている部分もあり、気を許すと夏にひどい目にあうかもしれない。
これまで次のようにしてきた：
- UPS をApcupsd で監視・ネットワーク共有し、
- 定義した停電状態（瞬電や短い時間の停電はUPS で乗り切る）に達したらVMware やその他の端末を自動的に安全に終了し、
- UPS をシャットダウンし、復電を待つ
- 復電したら、定義した充電状態（バッテリーの充電が浅いと機器が起動したときにUPSが落ちるかもしれないから）になるまで待機し、
- 安全に起動できる状態になったらUPS を起動し、
- telnet でRT57i を再起動し、
- 起動した旨を管理者に通達し、
- DDNS を更新する
復電した際の起動順序もあるのだろうが、様々ある機器のうち RT57i だけが復帰できなかったから telnet で強制的に再起動させていたが、その後のテストで telnet すら受け付けない状態になることがあるのを発見した。
この状態でも、RT57i はシリアル接続は生きていることがわかったから、RS232-C ケーブルでを接続、USB 変換してWindows 端末からハイパーターミナルもしくはTeraTerm で再起動させることに成功した。（変換ケーブルはこれが使えた）
今度はこれをLinux（Ubuntu）が自動的に行うようにしなければならないし、ネットワークが正常なのかどうかも判定させなければならない。
スポンサードリンク
期待する動作は次のとおり：
- 起動時かcron で周期的にRT57i にネットワーク通信ができるか試みる
- 通信が確立できないときはシリアル通信を開始してRT57i を再起動させる
ネットワーク通信ができるかの判定
まず、RT57i の状態。停電から復帰すると、なぜか電源のOn/Off が必要になる。この時、RT57i に設定してある 192.168.100.1 と通信できないが、シリアル通信はできる。
今までtelnet で再起動させていたが、RT57i に接続できないからネットワーク経由では何も出来ない。できないときに限ってシリアル通信で再起動させるわけだから、「通信できるか」と「再起動」を分けて考える必要がある。
いろいろ探してみた結果、次のコマンドが良さそう。
ping -w 1 $ip | grep ‘パケット損失 100%’ > /dev/null && echo $ip && echo $ip | mail -s ‘ALERT server down!!’ < Your mail address >
（「Kozupon.com – 簡単サーバ監視シェル「監視君」の利用！」より引用）
検証スクリプト
rt57i-net.sh
#!/bin/sh
echo "---------------------------------"
echo " RT57i Restarter for Serial port"
echo "---------------------------------"
# init
addr=192.168.100.100
#addr=192.168.100.111
# ping check
ping_check(){
ping -w 1 $addr | grep '100% packet loss'>/dev/null && return 1
return 0
}
#
# main
#
echo " - pinging..."
ping_check
if [ $? = 1 ]
then
echo " - Network Status [ FAIL ]"
`kermit rt57i-s2.macro`
else
echo " - Network Status [ O K ]"
fi
exit 0
テスト
$ sh rt57i-net.sh
これを起動時やcron で実行させれば問題解決となるかな。。。
※機器の起動順序を云々するなら、インテリジェントなUPS などを使うと制御できるが…￥
※この手の不具合は再現させるのが難しい。一発勝負的な要素も…。
参考文献
- UNIXの部屋 コマンド検索:戻り値 (*BSD/Linux)
- Kozupon.com – 簡単サーバ監視シェル「監視君」の利用！
- UNIXシェルスクリプトメモ(Hishidama’s UNIX shell script Memo)
コメント