Linux 立上げで自動バックアップ

以前 systemd の実習を兼ねて、立上げ時に1度だけ実行させるサービスを組込んでいますが、その備忘録の整理と一部の拡張が必要なために修正と補足を追加してまとめます。

バックアップ先の選択が必要になり修正

普段使いのノートPC がデュアルブートで、時々裏の Windows10 を利用することがあります。普段は Linux の Ubuntu が立上がったまま稼働し利用しています。

そこで Linux が立上がった時に、Windows システム側の ntfs ファイルシステムの作業領域として更新される一部を自動的にバックアップしようと考えて、すでに組み込んで運用しています。

今回は、UPS バッテリーが追加された NET共有サーバーとしてラズパイ1B+を立上げていますが、これを主となるマスターとして位置付けて、今までのサーバーをシステムバックアップ用のスレーブとして共存することにしました。

ラズパイも接続される HDD が内部バスで高速なら、戸惑いなく RAID2 のミラーで利用するのですが、さすがに USB2.0 のインターフェース HDD でミラーを組むのは無理があると思い、2台のラズパイをマスターとスレーブで利用して、マスターが故障した場合にはスレーブに接続を切り替えることにしました。

データの同期については、夜中から明方にかけて毎日コピーすることで同期させます。

そのため、決め打ちだったバックアップ先のサーバーアドレスを柔軟に切り替えられる必要に迫られました。

以前まとめた内容を修正しながらシンプルに整理

実際に Windows を利用していたかは問題外として、Linux が起動した後に1度だけ ntfs の一部とサーバーのバックアップエリアの同期を取ります。その時に、バックアップを実行したタイムスタンプをバックアップエリア内に残しておくこととします。

パッケージ名: NoteStartUpRun で、指定する場所に実際の実行モジュール等を配置します。

ユニットファイル名: note-startup-1st.service が、サービスの性格を定義する仕様書の位置付けです。このサービス名をキーにして、実行結果のログ確認や動作状況の確認ができます。

サービス(ユニットファイル)の登録は、 /etc/systemd/system/note-startup-1st.service です。

サービスとして実際に実行するモジュールは、パッケージ名で指定するディレクトリ /opt/NoteStartUpRun/bin に集めます。

まずサービスの仕様書となるユニットファイルの作成ですが、一般ユーザーのホームで作成して、systemd のシステム領域にコピーします。

$ vi note-startup-1st.service
[Unit] 
Description = Note Private AutoRun
After=network-online.target remote-fs.target nss-lookup.target
ConditionPathExists=/opt/NoteStartUpRun/bin

[Service]
ExecStart=/opt/NoteStartUpRun/bin/note-stup-1st.sh
Restart=no
Type=simple

[Install]
WantedBy=multi-user.target

作成したサービスを systemd 領域にコピーして、所有者とアクセス権の変更をします。

$ sudo cp note-startup-1st.service /etc/systemd/system
$ sudo chown root:root /etc/systemd/system/note-startup-1st.service
$ sudo chmod 644 /etc/systemd/system/note-startup-1st.service

サービスから起動するモジュールをシェルスクリプトで作成します。

これは単純にバックアップするスクリプトに制御を移しているだけです。後から引数の追加・変更等のカスタマイズが容易になると思われます。今回は、バックアップ先サーバーのIPアドレスを与えています。

$ vi note-stup-1st.sh
#!/bin/sh
exec /opt/NoteStartUpRun/bin/sunao-note_Windows-Documents-bkup  "192.168.11.23"

パッケージをまとめるディレクトリを作成して、所有権とアクセス権の設定を行い、起動するスプリクトを配置します。

$ sudo mkdir -p /opt/NoteStartUpRun/bin
$ sudo chmod 755 /opt/NoteStartUpRun/bin
$ sudo cp note-stup-1st.sh /opt/NoteStartUpRun/bin
$ sudo chown root:root /opt/NoteStartUpRun/bin/note-stup-1st.sh
$ sudo chmod 755 /opt/NoteStartUpRun/bin/note-stup-1st.sh

実際にバックアップを実行するスクリプトを作成します。

$ vi sunao-note_Windows-Documents-bkup
#!/bin/bash

server='192.168.11.23' # バックアップ先サーバー
test -z "$1" || server="$1"
echo "-- bkup to $server"

bkup_D="$server:/home/bkup/sunao-sp/sunao-Win-Doc/" # バックアップ先位置

mntS='/mnt/ntfs'
bkup_S="$mntS/Users/sunao/Documents/" # バックアップ元のベース

sleep 300 # 安定するように 5分待つ
/bin/mount $mntS
echo "実行タイムスタンプ `date`" > $bkup_S/TimeStamp.txt
/usr/bin/rsync -av --delete $bkup_S $bkup_D
/bin/umount $mntS

バックアップを実行するスクリプトを配置して、所有権とアクセス権を設定します。

$ sudo cp sunao-note_Windows-Documents-bkup /opt/NoteStartUpRun/bin
$ sudo chown root:root /opt/NoteStartUpRun/bin/sunao-note_Windows-Documents-bkup
$ sudo chmod 755 /opt/NoteStartUpRun/bin/sunao-note_Windows-Documents-bkup 

処理の流れとしては、サービスとして定義している note-startup-1st.service により note-stup-1st.sh が起動されます。その中で単純にバックアップ実行スクリプトの sunao-note_Windows-Documents-bkup を起動しています。


ユニットファイルを systemd に登録

ここからは、systemd へのサービス(ユニットファイル)の登録と検証作業です。

ユニットファイル等を追加や変更した後には、必ず次のコマンド sudo systemctl daemon-reload を実行します。systemd への登録や登録内容の更新作業が必要になるようです。

そして一緒にステータスも確認しておきます。

$ sudo systemctl daemon-reload
$ sudo systemctl status note-startup-1st.service
● note-startup-1st.service - Note Private AutoRun
   Loaded: loaded (/etc/systemd/system/note-startup-1st.service; disabled; vendor preset: enabled)
   Active: inactive (dead)

ステータスで表示される Loaded: 行のカッコ内の1つ目と2つ目のセミコロンの間の disabled となっているのは、自動起動が無効になっているということのようで、自動起動できるように設定します。

自動起動が行われるように設定

$ sudo systemctl enable note-startup-1st.service
Created symlink from /etc/systemd/system/multi-user.target.wants/note-startup-1st.service to /etc/systemd/system/note-startup-1st.service.
$ sudo systemctl status note-startup-1st.service
● note-startup-1st.service - Note Private AutoRun
   Loaded: loaded (/etc/systemd/system/note-startup-1st.service; enabled; vendor preset: enabled)
   Active: inactive (dead)

ユニットファイルの定義内に、[ Install ] の WantedBy= で定義しているユニットにリンクが張られ、先ほどの /etc/systemd/system/note-startup-1st.service; の後の disabledenabled に変わっています。

これで再立ち上げで自動実行されるようになっているはずですが、その前にコマンドで起動して確認します。

systemd の手動起動の確認

ユニットファイル名を指定したコマンド sudo systemctl start note-startup-1st.service で起動できます。

$ sudo systemctl start note-startup-1st.service
$ sudo systemctl status note-startup-1st.service
● note-startup-1st.service - Note Private AutoRun
Loaded: loaded (/etc/systemd/system/note-startup-1st.service; enabled; vendor preset: enabl
Active: active (running) since Sat 2019-02-09 20:40:50 JST; 19s ago
Main PID: 15710 (sunao-note_Wind)
Tasks: 2 (limit: 3787)
CGroup: /system.slice/note-startup-1st.service
├─15710 /bin/bash /opt/NoteStartUpRun/bin/sunao-note_Windows-Documents-bkup 192.168
└─15711 sleep 300

2月 09 20:40:50 MITA-NY40S systemd[1]: Started Note Private AutoRun.
2月 09 20:40:50 MITA-NY40S note-stup-1st.sh[15710]: -- bkup to 192.168.11.23
lines 1-11/11 (END)

起動されて ‘– bkup to 192.168.11.23′ のメッセージまでが書きだされて、’Active: active (running) since ….’ と表示して実行中なのがわかり、’└─15711 sleep 300′ で止まっているのが確認できます。

待ち時間の5分が経過したので、再び確認してみます。

$ sudo systemctl status note-startup-1st.service
● note-startup-1st.service - Note Private AutoRun
   Loaded: loaded (/etc/systemd/system/note-startup-1st.service; enabled; vendor preset: enabl
   Active: inactive (dead) since Sat 2019-02-09 20:45:57 JST; 24min ago
  Process: 15710 ExecStart=/opt/NoteStartUpRun/bin/note-stup-1st.sh (code=exited, status=0/SUC
 Main PID: 15710 (code=exited, status=0/SUCCESS)

 2月 09 20:45:51 MITA-NY40S ntfs-3g[15727]: Version 2017.3.23 integrated FUSE 28
 2月 09 20:45:51 MITA-NY40S ntfs-3g[15727]: Mounted /dev/sda4 (Read-Write, label "Windows", NT
 2月 09 20:45:51 MITA-NY40S ntfs-3g[15727]: Cmdline options: rw,noexec,nosuid,nodev,uid=1000,g
 2月 09 20:45:51 MITA-NY40S ntfs-3g[15727]: Mount options: rw,noexec,nosuid,nodev,user,allow_o
 2月 09 20:45:51 MITA-NY40S ntfs-3g[15727]: Global ownership and permissions enforced, configu
 2月 09 20:45:55 MITA-NY40S note-stup-1st.sh[15710]: sending incremental file list
 2月 09 20:45:56 MITA-NY40S note-stup-1st.sh[15710]: TimeStamp.txt
 2月 09 20:45:57 MITA-NY40S note-stup-1st.sh[15710]: sent 4,207 bytes  received 61 bytes  948.
 2月 09 20:45:57 MITA-NY40S note-stup-1st.sh[15710]: total size is 37,355,511  speedup is 8,75
 2月 09 20:45:57 MITA-NY40S ntfs-3g[15727]: Unmounting /dev/sda4 (Windows)
lines 1-16/16 (END)

コマンドによる起動では問題なく実行されて、正常終了しているようです。

ログに書き出されている内容から、最初の status では sleep 300 で停止しているので、その時点までの echo メッセージが確認でき、次の status では、その後の ntfs ファイルのマウントや rsync コマンドによる転送や ntfs ファイルのアンマウントが記録されています。

もし更新ファイルのバックアップで、更新されていれば、ここにファイル名がリストされていると思います。

この処理は、起動されてバックアップ動作が終わると、毎回終了するので ‘Active: inactive (dead)’ と表示して、その後に終了した日時が記録されています。

一般ユーザーでジャーナルを確認

次にプログラムの出力ログを確認できる journalctl コマンドがあるので確認してみます。

$ journalctl -u note-startup-1st.service

 2月 09 20:40:50 MITA-NY40S systemd[1]: Started Note Private AutoRun.
 2月 09 20:40:50 MITA-NY40S note-stup-1st.sh[15710]: -- bkup to 192.168.11.23
 2月 09 20:45:51 MITA-NY40S ntfs-3g[15727]: Version 2017.3.23 integrated FUSE 28
 2月 09 20:45:51 MITA-NY40S ntfs-3g[15727]: Mounted /dev/sda4 (Read-Write, label "Windows", NT
 2月 09 20:45:51 MITA-NY40S ntfs-3g[15727]: Cmdline options: rw,noexec,nosuid,nodev,uid=1000,g
 2月 09 20:45:51 MITA-NY40S ntfs-3g[15727]: Mount options: rw,noexec,nosuid,nodev,user,allow_o
 2月 09 20:45:51 MITA-NY40S ntfs-3g[15727]: Global ownership and permissions enforced, configu
 2月 09 20:45:55 MITA-NY40S note-stup-1st.sh[15710]: sending incremental file list
 2月 09 20:45:56 MITA-NY40S note-stup-1st.sh[15710]: TimeStamp.txt
 2月 09 20:45:57 MITA-NY40S note-stup-1st.sh[15710]: sent 4,207 bytes  received 61 bytes  948.
 2月 09 20:45:57 MITA-NY40S note-stup-1st.sh[15710]: total size is 37,355,511  speedup is 8,75
 2月 09 20:45:57 MITA-NY40S ntfs-3g[15727]: Unmounting /dev/sda4 (Windows)
lines 285-306/306 (END)

ジャーナルの表示では、status で分割されていたログ内容が続けて表示され、 20:40 で処理が始まり、時間が飛んで 20:45 から ntfs のマウントが始まっているので、5分待っているのが確認できます。

システム再起動による自動起動の確認

いよいよ待望の Linux の立上げによる自動起動の確認になります。ノートPCを再起動してジャーナルを確認します。

$ journalctl -u note-startup-1st.service

 2月 09 20:45:57 MITA-NY40S note-stup-1st.sh[15710]: sent 4,207 bytes  received 61 bytes  948.44 bytes/s
 2月 09 20:45:57 MITA-NY40S note-stup-1st.sh[15710]: total size is 37,355,511  speedup is 8,752.46
 2月 09 20:45:57 MITA-NY40S ntfs-3g[15727]: Unmounting /dev/sda4 (Windows)
-- Reboot --
 2月 09 22:00:30 MITA-NY40S systemd[1]: Started Note Private AutoRun.
 2月 09 22:00:30 MITA-NY40S note-stup-1st.sh[1281]: -- bkup to 192.168.11.23
 2月 09 22:05:31 MITA-NY40S ntfs-3g[3854]: Version 2017.3.23 integrated FUSE 28
 2月 09 22:05:31 MITA-NY40S ntfs-3g[3854]: Mounted /dev/sda4 (Read-Write, label "Windows", NTFS 3.1)
 2月 09 22:05:31 MITA-NY40S ntfs-3g[3854]: Cmdline options: rw,noexec,nosuid,nodev,uid=1000,gid=1000,use
 2月 09 22:05:31 MITA-NY40S ntfs-3g[3854]: Mount options: rw,noexec,nosuid,nodev,user,allow_other,nonemp
 2月 09 22:05:31 MITA-NY40S ntfs-3g[3854]: Global ownership and permissions enforced, configuration type
 2月 09 22:05:34 MITA-NY40S note-stup-1st.sh[1281]: sending incremental file list
 2月 09 22:05:35 MITA-NY40S note-stup-1st.sh[1281]: TimeStamp.txt
 2月 09 22:05:35 MITA-NY40S note-stup-1st.sh[1281]: sent 4,207 bytes  received 61 bytes  948.44 bytes/se
 2月 09 22:05:35 MITA-NY40S note-stup-1st.sh[1281]: total size is 37,355,511  speedup is 8,752.46
 2月 09 22:05:35 MITA-NY40S ntfs-3g[3854]: Unmounting /dev/sda4 (Windows)
lines 295-319/319 (END)

‘– Reboot –‘ の記録以降が新しく追加されたログですので、問題なく起動されて正常終了しているようです。


実際の立上げによるバックアップの注意点

順調にバックアップ動作が機能したわけではなく、色々な試行錯誤の結果として問題の解決ができています。

立上げ直後は、ネットワークの安定に問題があるらしくエラーになっていました。対策としては起動されてから 5分の待ち時間の追加で問題が解決しました。

次は ‘sleep 300’ の待ち時間が追加される前に出ていたエラーのジャーナル内容です。

$ journalctl -u note-startup-1st.service

-- Logs begin at 火 2018-01-09 16:24:34 JST, end at 火 2018-01-09 16:27:17 JST. --
 1月 09 16:25:12 MITA-NY40S systemd[1]: Started Note Private AutoRun.
 1月 09 16:25:14 MITA-NY40S ntfs-3g[1071]: Version 2015.3.14AR.1 integrated FUSE 28
 1月 09 16:25:14 MITA-NY40S ntfs-3g[1071]: Mounted /dev/sda4 (Read-Write, label "Windows", NTFS 3.1)
 1月 09 16:25:14 MITA-NY40S ntfs-3g[1071]: Cmdline options: rw,noexec,nosuid,nodev,uid=1000,gid=1000,user
 1月 09 16:25:14 MITA-NY40S ntfs-3g[1071]: Mount options: rw,noexec,nosuid,nodev,user,allow_other,nonempty,relatime,default_permissi
 1月 09 16:25:14 MITA-NY40S ntfs-3g[1071]: Global ownership and permissions enforced, configuration type 7
 1月 09 16:25:16 MITA-NY40S note-stup-1st.sh[1039]: ssh: connect to host 192.168.11.21 port 22: Network is unreachable
 1月 09 16:25:16 MITA-NY40S note-stup-1st.sh[1039]: rsync: connection unexpectedly closed (0 bytes received so far) [sender]
 1月 09 16:25:16 MITA-NY40S note-stup-1st.sh[1039]: rsync error: unexplained error (code 255) at io.c(226) [sender=3.1.1]
 1月 09 16:25:16 MITA-NY40S ntfs-3g[1071]: Unmounting /dev/sda4 (Windows)

それ以外のエラーとして、バックアップ先のサーバーを変更したらエラーになりました。

理由は root ユーザーで接続し転送していますが、 root から root での ssh での接続実績がなく、確認キー待ちになってエラーしていたようです。事前にサーバーへの接続確認をしておく必要があるようです。

-- Reboot --
 2月 07 23:09:20 MITA-NY40S systemd[1]: Started Note Private AutoRun.
 2月 07 23:09:20 MITA-NY40S note-stup-1st.sh[1330]: -- bkup to 192.168.11.23
 2月 07 23:14:21 MITA-NY40S ntfs-3g[2633]: Version 2017.3.23 integrated FUSE 28
 2月 07 23:14:21 MITA-NY40S ntfs-3g[2633]: Mounted /dev/sda4 (Read-Write, label "Windows", NTFS 3.1)
 2月 07 23:14:21 MITA-NY40S ntfs-3g[2633]: Cmdline options: rw,noexec,nosuid,nodev,uid=1000,gid=1000,use
 2月 07 23:14:21 MITA-NY40S ntfs-3g[2633]: Mount options: rw,noexec,nosuid,nodev,user,allow_other,nonemp
 2月 07 23:14:21 MITA-NY40S ntfs-3g[2633]: Global ownership and permissions enforced, configuration type
 2月 07 23:14:21 MITA-NY40S note-stup-1st.sh[1330]: Host key verification failed.
 2月 07 23:14:21 MITA-NY40S note-stup-1st.sh[1330]: rsync: connection unexpectedly closed (0 bytes recei
 2月 07 23:14:21 MITA-NY40S note-stup-1st.sh[1330]: rsync error: error in rsync protocol data stream (co
 2月 07 23:14:21 MITA-NY40S ntfs-3g[2633]: Unmounting /dev/sda4 (Windows)

ラズパイで ネットチューナー

長く生きていると誰にでもじわじわと押し寄せる老朽化ですが、私の頭もご多分に漏れず処理能力がかなり落ちていると思います。処理は遅いし途中で別の優先事項が割り込むと、元の作業が長期中断したり継続の見込みのない保留になったりしています。

仕掛り中のラズパイ1B+のネット共有サーバーも少し保留で、1年以上前に設定して有効な利用もないまま据え置かれたラズパイがあり、こちらは妻が使用しているステレオに接続して試用をして、その後そのまま据え置かれていました。

ラズパイに専用のDACを重ねて、ミュージックサーバーの専用OS – Volumio2を入れて利用する物です。WiFi経由でネットに接続したら音飛びが酷くて、経過見で置かれてそのままになってしまったようです。忘れましたが、WiFi機能があるのでラズパイ3B でしょうね。

ラズパイもサーバーとして長く稼働していると、原因が相性なのか性能なのか不明ですが、 SD のシステムやデータが壊れるのを度々経験していて、ちょっと心配です。そんなこともあって、相性が良いと評判の東芝製 microSD をわざわざ購入して設定しました。今回は稼働したまま1年以上置かれていましたが、壊れてはいませんでした。

妻が独身時代から利用していたステレオが老朽化して、電解コンデンサや機械的に可動するボリューム類も対応不能な状況になって、当時手軽な価格でネットで購入できるメインアンプとしてマランツの PS3001 を購入しました。これが、接続もされないままひっそりと片隅に置かれたままになっていました。

それをバックグラウンド・ミュージックのシステムとして使おうと考えて、スピーカーも購入していました。邪魔にならないように静かに音が流れるだけの環境での使用なので、大きなスピーカーの必要もなくて安い手頃なものを購入していました。これが今回は日の目を見ることになりました。

自分の部屋にマランツの大きくて重いアンプと小さな Volumio のラズパイを運びスピーカーを接続しました。日の目を見たミュージックサーバーは何の問題もなく音を出し始めました。

1年以上前にセットアップしたシステムなので、当然のように新しいシステムが提供されていました。悩むところですが今後のこともあるので、経験としてアップデートしてどのような結果になるのか興味があるし知りたいところです。そんなわけで、Volumio2 システムのアップデートも試してみました。

見た目は問題なくアップデートできたようです。この時点で止めといても良かったのですが、ネット上には NHK のラジオを組込む記事なども見付けることができ、プラグインを2つ組込んで対応できたようなので試してみようと考えました。
プラグインの組込みを実行すると、どれを選んでも同じエラーになります。古いシステム情報との競合のようです。ssh でログインして、update や upgrade を試してみましたが、システム全体の作りが元は同じ raspbian を使用しているもののモジュールの更新は考慮していないようです。

そこで最初からのクリーンインストールを試して、動作の違いを検証してみようと思い立ちました。そこで問題なのが選択してせっかく作った playlist を保存しておき、最新の Volumio2 のインストール後に戻すことができるかです。

置かれたディレクトリの情報をネットで色々と調べました。でも肝心なディレクトリの情報になかなか辿り着けないで困りました。

全てがそうなのかは分かりませんが、ルート下の data ディレクトリに置かれているようです。例えば、/data/playlist/ の中に、オーナーが volumioユーザーとして、プレイリストのタイトル項目毎にファイルとして分かれて置かれていました。

リモートで作業しているノートPCから、scp コマンドで取り出すことも、戻すことも問題なく出来るようです。例えば、保管用のディレクトリを確保してから、次のようなコマンドで取り出して、新しいシステムをセットアップします。

$ mkdir -p ~/volumio/playlist
$ scp -r volumio@192.168.22.33:/data/playlist/*  ~/volumio/playlist/

作業しているノートPCの volumio/playlist/ に取り出せているので、新しいシステムをクリーンインストール後に、戻すために scp コマンドを利用します。

$ scp -r ~/volumio/playlist/*  volumio@192.168.22.33:/data/playlist/

最新の Volumio2 をセットアップした後で、悩んだことをメモしておきます。それは基本的なことで、ssh したかったのにできなくて困りました。1年前もたしか悩んだような記憶があります。方法はブラウザで、Volumio の /DEV にアクセスして、ssh を有効にする [enable] ボタンをクリックすることです。

なお、初期値のパスワードは、volumioroot も ‘volumio‘ になっているので置き換えを実行しておきます。

最新版の Volumio2 をクリーンインストールしたので、できなかったプラグインは問題なくインストールまでできました。しかし、ネットで紹介された手順の途中で、:9000 番ポートにアクセスして操作するように説明されているのですが、そのポートでは機能が待ち受けていないようで、この作業は保留になりました。

暇ができたら頭の体操としてこの続きを進めたいと思いますが、ただのネットチューナーとしてだけでも十分なバックグラウンド・ミュージックサーバーとして働いています。この先も暇などできないと思うのでこの件は長期保留ですね。

最初からリストされている多くの放送局は動作保証されてませんが、感覚的には半分くらいはまともに機能しているようで、日本の歌謡曲やアイドルの局を流している放送局もあります。時折少し訛った日本語で日本の天気予報や鉄道情報が流れるのもありましたし、曲目や歌手名が漢字で表示されるのもあります。

バックグラウンドで適当に色々な曲が流れるのは私の性に合っているのかもしれません。特に信仰する歌手や曲があってこだわるわけでもないので、わざわざ選んだり入替えたりする手間も必要なくとても合理的です。今はこんな曲が欲しいと大雑把に放送局を選ぶだけで事が済みます。

音量のボリューム操作や放送局の選択は、離れたPCからのブラウザ操作でも、スマホからの操作でもできるし、もし必要なら曲名やアーティスト名の確認も簡単な内容ですが一応できます。今現在は、こんな曲もあったよなぁ〜と思うような懐かしい青春時代の曲が次から次へと流れています。

家に置かれたアナログの固定電話でもバックではデジタルのネットワーク経由だし、すでにラジオも時代は電波を使って放送する時代からネットワークを経由する時代に移行しているのですね、有料放送の NHK はこだわりから時代に遅れてますが今後どうなるのでしょうね。
放送局は、聞ききれないほどの選択量があるので、飽きたら変えるとか気分で変えるとか、良い悪いの判断は一度選んでみないと分からないので、埋もれる局が溢れてます。

ラズパイUPSのメール

ラズパイ1B+のネット共有サーバー化で、UPSバッテリーの減少や充電の経過をメール送信させて、スマホで確認したい、との対策の続きです。

メール機能は、今迄のサーバー設定の流れからpostfixでの設定になりますが、以前の実績のあるサーバーの設定と比較しながら今回も設定しました。一応動作したように感じたのですが、送られてくるはずのログが届きませんでした。

postfixのバージョンも上がっていて、項目が少し増えているようです。丹念に見直すと一部がコメントのままになっている項目とか別に誤りとか、数件気になる場所が見つかりました。

そこを直して立ち上げ直すと、期待しているような送信が行なわれているような印象です。届かなかったログも時間を置いて再送信されたようで、数時間後に届きました。

メモとして、コメントを除いた有効行をリストしておきます。

$ cat /etc/postfix/main.cf
compatibility_level = 2
command_directory = /usr/sbin
daemon_directory = /usr/lib/postfix/sbin
data_directory = /var/lib/postfix
mail_owner = postfix
myhostname = rpi1-disk.sunao-mita.pgw.jp
mydomain = sunao-mita.pgw.jp
myorigin = $myhostname
inet_interfaces = all
mydestination = rpi1-disk, DebianPogo, DebianPogo.$mydomain, $myhostname, localhost, $mydomain
local_recipient_maps = unix:passwd.byname $alias_maps
unknown_local_recipient_reject_code = 550
mynetworks_style = host
mynetworks = 127.0.0.0/8, 192.168.11.0/24, [::ffff:127.0.0.0]/104 [::1]/128, [240d:1a:34d:7f00::0]/64
relayhost = [smtp.nifty.com]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/nifty.auth
smtp_sasl_security_options = noanonymous
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
home_mailbox = Maildir/
smtpd_banner = $myhostname ESMTP
debugger_command =
         PATH=/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
         ddd $daemon_directory/$process_name $process_id & sleep 5
sendmail_path = /usr/bin/postfix
newaliases_path = /usr/bin/newaliases
mailq_path = /usr/bin/mailq
setgid_group = postdrop
inet_protocols = ipv4, ipv6
message_size_limit = 10485760
mailbox_size_limit = 1073741824
smtpd_sasl_type = dovecot
smtpd_sasl_path = private/auth
smtpd_sasl_auth_enable = yes
smtpd_sasl_security_options = noanonymous
smtpd_sasl_local_domain = $myhostname
smtpd_recipient_restrictions = permit_mynetworks, permit_auth_destination, permit_sasl_authenticated, reject
mua_client_restrictions = permit_sasl_authenticated,reject
mua_helo_restrictions = permit_sasl_authenticated,reject
mua_sender_restrictions = permit_sasl_authenticated,reject

mailコマンドでメールするのに、以前は問題なく送信できていたのに、最近のバージョンではサーバー名が短縮されて送信されるようで、リレー先の@niftyでエラーになってしまいます。

どこかの定義で変更できるのかと思い調べたのですが、私には見つけられませんでした。対策としては、-r オプションで、リターンアドレスをフルアドレスで明示して指定することで回避できました。

メールで経過を送信できる目処が立ったので、どのように作るかですが、作成したups-readでバッテリーの容量が取得できるので、単純なシェルスクリプトで容量の変化を検知してメールを作成させることにしました。

バッテリーの減少検知では、50%を切ったら10%減少毎にメールをスマホに送信します。充電では、50%を越えたら15%充電毎にメールをスマホに送信します。

起動方法は、cronにより適当なインターバルで、毎回起動し過去と比較判定して該当すればメールを作成して終了します。

起動された前回の容量とメールを作成した時の容量をファイルに記録しておいて比較する方法です。経過をモニタしながらのデバッグで分かったことは、ups-readから渡される容量が、有り得ない数値を頻繁に表示します。

0 〜 100の範囲を超えて、120 程度は想定内と認識しますが、217 とか 193 などといった異常な数値が頻繁に出てきます。観察すると異常な数値に混じって正常な数値も有るようです。

異常な数値を排除した 0 〜 120 の範囲に入る数値は 、安定していて変化の少ない数値で推移しています。期待するバッテリーの容量と判断しても良さそうです。

対策としては、120 を超える異常な数値の時には前回の数値と置換えて無視することにしました。

$ cat bin/ups-check-mail.sh
#!/bin/bash

T='## UPS Battery Capacity ##'
Msg='UPS Battery Capacity '
DW='*Down* : '
UP='*Up* : '
Rt='sunao@rpi1-disk.sunao-mita.pgw.jp'
To='sunao*****@yahoo.**.jp'    # スマホのメールアドレス

FC='UPS-Check/UPSCap.txt'      # 前回の容量メモ
FM='UPS-Check/UPSCap-msg.txt'  # メール生成時の容量メモ

C=`ups-read`
test -f $FC || echo 100 > $FC  # メモファイルが無い場合
test -f $FM || echo 100 > $FM  # メモファイルが無い場合

UPSCap=`cat $FC`
UPSmsg=`cat $FM`
test $C -gt 120 && C=$UPSCap  # 120% を越えていれば異常と判断し、前回値に補正

if [ $C -lt $UPSCap ]; then  ### 放電 ; 前回との減少変化を検知
  if [ $C -lt 50 ] && [ $((C+9)) -lt $UPSmsg ]; then  # < 50% ; 10% 減少毎にメール作成
    echo $C > $FM

    Tl=`echo "$T" | sed -r "s/( ##)$/ *DOWN* ( $C% )\1/"`  # 減少メールのタイトル作成
    # echo "タイトル: $Tl"  # debug 確認用
    echo -e "`date`\n$Msg$DW$C %" | mail -s "$Tl" -r "$Rt" "$To"    # メールの転送
  fi
else
  if [ $C -gt $UPSCap ]; then  ### 充電 ; 前回との増加変化を検知
    if [ $C -gt 50 ] && [ $((C-14)) -gt $UPSmsg ]; then  # 50% < ; 15% 増加毎にメール作成
      echo $C > $FM

      Tl=`echo "$T" | sed -r "s/( ##)$/ *UP* ( $C% )\1/"`  # 増加メールのタイトル作成
      # echo "タイトル: $Tl"  # debug 確認用
      echo -e "`date`\n$Msg$UP$C %" | mail -s "$Tl" -r "$Rt" "$To"    # メールの転送
    fi
  fi
fi
echo $C > $FC  # 今の容量を記録

AC100V電源を止めても、2時間近くはバッテリーで動作していますが、しばらく待っているとスマホにメールが送られてきます。

備忘録として、単体での起動なら例えば /home/sunao/bin/ の下にスクリプトを置いて起動できますが、cron からの起動ではスクリプトが見付けられずにエラーとなります。cron では、最低限のPATH設定となっているからです。

crontab -e で、起動時間や起動スクリプトを編集する定義の中で、さらに先の行に、PATH= 定義を記述して実行モジュールを読み込むディレクトリをリストしておくとパスが省略されていても起動できるようです。

$ crontab -e

# m h  dom mon dow   command
PATH=/home/sunao/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

##### UPS バッテリーの変化でメール作成 ######
*/5 * * * * ups-check-mail.sh > /dev/null

スマホには、8 〜 9 分間隔で 10%減のメールが届きます。逆に充電時は、11 〜 12 分間隔で 15%増のメールが届きます。気休めですがメールが送られると少し安心できます。

まだ手を加えたい箇所はあるもののネット共有サーバーとして利用できそうな状況になってきました。

ラズパイにUPS機能を組込む

ラズパイ1B+をネットワーク共有サーバーとして、バッテリーバックアップを行いながら常時起動しておくことを考えています。

以前、普段使いのノートPCのLinux(Ubuntu)立上げ後に、ネットワーク共有サーバー上に自動的に、Windowsファイルの一部をバックアップするsystemdのサービスを追加したことがあり、同様に常時起動のラズパイ1B+にバッテリー監視のサービスを起動しようと考えました。

今回の作業背景

何となく思いつきで購入した安価な製品で、ラズパイに装着できる制御ボードバッテリーのセットです。特に付属の説明も無いものでアマゾンで購入しました。

Raspi UPS HAT Board と呼ばれているようで、資料が公開されています。

この公開資料では色々と説明されていて、サンプルコードも多数提示されているのですが、何か詰が甘くて動作を検証しても思うような結果が出ません。そのまま手を加えなくても期待した結果だったモジュールは、C言語で記述された File:Ups-hat-c.zip だけでした。これはモジュールとして解説の手順でコンパイルすると、ups-read となります。

利用方法としては、引数を [付ける/付けない] により少し異なりますが、バッテリー電圧とバッテリー容量が取得できます。

解説の中には、root権限で実行するためにパスワード無しの sudo を冠して実行するための /etc/sudoers の追加記述がありますが、最新の raspbian では単純にユーザー権限のままでも実行できるようでした。

引数無しでは、バッテリー容量がパーセンテージで表した整数値のみで返されます。これはバッテリー制御ボードから直接受け取った情報を特定の関数で変換していると思われますが、ちょっとした落とし穴があって、0〜100 ではない場合があり、 割合を表す数値としてはありえない 120 とか 112 とかになっていることがあります。

引数には、vc が指定でき、両方指定すれば電圧と容量が、当てにならない小数点以下6桁で、3.498750V 9.480469% のように表示されます。10秒毎にリストにして確認してみましたが、電圧の変化と容量の変化にはある程度の相関関係があるようです。ラズパイの処理で負荷動作による揺れなのか、数値に振れが見受けられます。

ちなみに、0.000000% でも動作していますが、電圧値が、3.000000V を下回った頃に、一気に電力不足でシステムが停止しているようでした。容量が 5.000000% 以下になったのを見て正常な停止処理に移行させた方が良さそうです。

作ろうとしている私のネットワーク共有サーバーとしての動作環境は、ラズパイ1B+ 2TB 2.5インチ HDD で構成されています。フル充電から 5.0% まで容量が減衰する動作継続時間は、優に1時間を越えています。ある程度バッテリーが劣化しても余裕がありそうです。

先程の公開資料ですが、その中で提供されているサンプルは、ほぼ python で記述されていて、I2Cインタフェースからバッテリーの電圧と容量を取得するルーチンが紹介されています。


その中に UPS のバッテリーを監視して shutdown を起動するサンプルが次の項目に紹介されています。

Driver and Sample code

  • File:Rpi-ups-hat.zip
  • File:UserManual.pdf

zip を解凍すると、rpi-ups-hat ディレクトリ下に example.py と raspiupshat.so があります。raspiupshat.so が、UPSのバッテリー電圧と容量を取得できるライブラリです。

example.py では、そのライブラリを利用して、無限ループで容量をチェックして、5% を切ると shutdown コマンドが起動される例として記述されています。

残念なことに、os.system(“sudo shutdown”) の行で、ライブラリ os が import されていないため、エラーメッセージを表示して終了してしまいます。

UserManual.pdf は、英語と中国語?で書かれた利用条件の説明です。その中で wiringPi のインストールが必須として書かれていますが、最新の raspbian では事前にセットアップされているようです。

これを流用させて頂き、UPS制御を組込む予定です。


systemd のサービスとして起動する方法については、次のサイトを参考に制作しますが、一度私のノートPCで作成した経験があるので、自分の備忘録も見返しながらの作業になります。

参考にしたサイトは、作り方を事細かく説明してくれています。


ここからが作業の本題

Raspbian 起動時に、一度だけ起動して常時バッテリーを監視して、容量が 5% を下回った時に shutdown プロセスを起動させます。

systemd に登録するサービスの指示書が、ユニットファイルとのことです。

パッケージ名: UPS-Watch-shut で、ユニットファイル名: ups-watching.service としてみました。

サービス(ユニットファイル)の登録は、 /etc/systemd/system/ups-watching.service で、この中には登録するサービスの情報を決められた書式で記述します。

そして実際に動作させるプログラムは、パッケージ名で管理するディレクトリに記述するようで、 /opt/UPS-Watch-shut/bin に集めるようです。バッテリーの情報を取得するライブラリ raspiupshat.so もここに置きます。

systemd の動作を確認する雛形作り

参考サイトがカレントで作成して、それを該当するディレクトリにコピーして、所有者を root に変更したり、アクセス権の変更をしているので、私もその方法を踏襲します。

$ vi ups-watching.service
[Unit] 
Description = UPS Watching AutoRun
After=network-online.target remote-fs.target nss-lookup.target
ConditionPathExists=/opt/UPS-Watch-shut/bin

[Service]
ExecStart=/opt/UPS-Watch-shut/bin/startup-1st.sh
Restart=no
Type=simple

[Install]
WantedBy=multi-user.target
$ sudo cp ups-watching.service /etc/systemd/system
$ sudo chown root:root /etc/systemd/system/ups-watching.service
$ sudo chmod 644 /etc/systemd/system/ups-watching.service
$ vi startup-1st.sh
#!/bin/sh
exec /usr/bin/env python /opt/UPS-Watch-shut/bin/ups-shutdown.py
$ sudo mkdir -p /opt/UPS-Watch-shut/bin
$ sudo chmod 755 /opt/UPS-Watch-shut/bin
$ sudo cp startup-1st.sh /opt/UPS-Watch-shut/bin
$ sudo chown root:root /opt/UPS-Watch-shut/bin/startup-1st.sh
$ sudo chmod 755 /opt/UPS-Watch-shut/bin/startup-1st.sh

実際に動作するサンプルプログラム

最終的に起動されるサンプルプログラムは、bash や ruby または python でも構わないのでしょうけど、参考サイトにある例をそのまま丸コピーしてきました。検証作業の説明も丁寧に行われているので、見比べるのにも最適なので利用させて頂いています。例では python で組まれた1秒毎にメッセージを書き出す無限ループの処理で、ups-shutdown.py として、次の記述です。

$ vi ups-shutdown.py
#!/usr/bin/env python
import sys
from time import sleep
if __name__ == '__main__':
  while True:
    print "Hello world %s" % (sys.argv)
    sys.stdout.flush()
    sleep(1)
$ sudo cp ups-shutdown.py /opt/UPS-Watch-shut/bin
$ sudo chown root:root /opt/UPS-Watch-shut/bin/ups-shutdown.py
$ sudo chmod 755 /opt/UPS-Watch-shut/bin/ups-shutdown.py 

サービスとして定義している ups-watching.service により startup-1st.sh が起動されます。その中で単純にサンプルプログラムの ups-shutdown.py を起動しています。

作成したユニットファイルやサンプルプログラムの確認

作成したユニットファイルやパッケージ内のプログラムの所有者とアクセス権の確認をしておきます。

$ ls -l /opt/UPS-Watch-shut
合計 4
drwxr-xr-x 2 root root 4096  1月  24 22:51 bin
$ ls -l /opt/UPS-Watch-shut/bin
合計 8
-rwxr-xr-x 1 root root  76  1月 24 22:49 startup-1st.sh
-rwxr-xr-x 1 root root 174  1月 24 22:51 ups-shutdown.py
$ ls -l /etc/systemd/system/ups-watching.service
-rw-r--r-- 1 root root 272 1月 24 22:47 /etc/systemd/system/ups-watching.service

茶色の部分の root ユーザーと 755 及び 644 が確認できました。

サンプルプログラムの単体動作検証

無限ループでメッセージを書き出すサンプルプログラムを単体で起動して、 [Ctrl+C] で強制停止して動作の確認をしておきます。

$ sudo /opt/UPS-Watch-shut/bin/ups-shutdown.py
Hello world ['/opt/UPS-Watch-shut/bin/ups-shutdown.py']
Hello world ['/opt/UPS-Watch-shut/bin/ups-shutdown.py']
Hello world ['/opt/UPS-Watch-shut/bin/ups-shutdown.py']
Hello world ['/opt/UPS-Watch-shut/bin/ups-shutdown.py']
Hello world ['/opt/UPS-Watch-shut/bin/ups-shutdown.py']
Hello world ['/opt/UPS-Watch-shut/bin/ups-shutdown.py']
Hello world ['/opt/UPS-Watch-shut/bin/ups-shutdown.py']
^CTraceback (most recent call last):
  File "/opt/UPS-Watch-shut/bin/ups-shutdown.py", line 8, in 
    sleep(1)
KeyboardInterrupt

単体では問題なくメッセージが書き出されるようです。


ユニットファイルを systemd に登録

ここからは、systemd へのサービス(ユニットファイル)の登録と検証作業です。ユニットファイル等を追加や変更した後には、必ず次のコマンド sudo systemctl daemon-reload を実行します。

そして一緒にステータスも確認しておきます。

$ sudo systemctl daemon-reload
$ sudo systemctl status ups-watching.service
● ps-watching.service - UPS Watching AutoRun
   Loaded: loaded (/etc/systemd/system/note-startup-1st.service; disabled; vendor preset: enabled)
   Active: inactive (dead)

ステータスで表示される Loaded: 行のカッコ内の1つ目と2つ目のセミコロンの間の disabled となっているのは、自動起動が無効になっているということのようで、自動起動できるように設定します。

自動起動が行われるように設定

$ sudo systemctl enable ups-watching.service
Created symlink /etc/systemd/system/multi-user.target.wants/ups-watching.service → /etc/systemd/system/ups-watching.service.
$ sudo systemctl status ups-watching.service
● ups-watching.service - UPS Watching AutoRun
Loaded: loaded (/etc/systemd/system/ups-watching.service; enabled; vendor preset: enabled)
Active: inactive (dead)

ユニットファイルの定義内に、[ Install ] の WantedBy= で定義しているユニットにリンクが張られ、先ほどの /etc/systemd/system/ups-watching.service; の後の disabledenabled に変わっています。

これで再立ち上げで自動実行されるようになっているはずですが、その前にコマンドで起動して確認したり、停止させる操作をして動作を確認します。

systemd の手動起動と停止の確認

ユニットファイル名を指定したコマンド sudo systemctl start ups-watching.service で起動できます。

$ sudo systemctl start ups-watching.service
$ sudo systemctl status ups-watching.service
 ups-watching.service - UPS Watching AutoRun
Loaded: loaded (/etc/systemd/system/ups-watching.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2019-01-24 23:21:56 JST; 13s ago
Main PID: 28546 (python)
CGroup: /system.slice/ups-watching.service
└─28546 python /opt/UPS-Watch-shut/bin/ups-shutdown.py

1月 24 23:22:01 rpi1-disk startup-1st.sh[28546]: Hello world ['/opt/UPS-Watch-shut/bin/ups-shu
1月 24 23:22:02 rpi1-disk startup-1st.sh[28546]: Hello world ['/opt/UPS-Watch-shut/bin/ups-shu
1月 24 23:22:03 rpi1-disk startup-1st.sh[28546]: Hello world ['/opt/UPS-Watch-shut/bin/ups-shu
1月 24 23:22:04 rpi1-disk startup-1st.sh[28546]: Hello world ['/opt/UPS-Watch-shut/bin/ups-shu

起動されて1秒毎にメッセージが書きだされているのが確認できます。

次は、sudo systemctl stop ups-watching.service コマンドで停止して結果をステータスで確認してみます。

$ sudo systemctl stop ups-watching.service
$ [
ups-watching.service - UPS Watching AutoRun
Loaded: loaded (/etc/systemd/system/ups-watching.service; enabled; vendor preset: enabled)
Active: inactive (dead) since Thu 2019-01-24 23:36:05 JST; 10s ago
Process: 28546 ExecStart=/opt/UPS-Watch-shut/bin/startup-1st.sh (code=killed, signal=TERM)
Main PID: 28546 (code=killed, signal=TERM)

1月 24 23:36:00 rpi1-disk startup-1st.sh[28546]: Hello world ['/opt/UPS-Watch-shut/bin/ups-shu
1月 24 23:36:01 rpi1-disk startup-1st.sh[28546]: Hello world ['/opt/UPS-Watch-shut/bin/ups-shu
1月 24 23:36:02 rpi1-disk startup-1st.sh[28546]: Hello world ['/opt/UPS-Watch-shut/bin/ups-shu
1月 24 23:36:03 rpi1-disk startup-1st.sh[28546]: Hello world ['/opt/UPS-Watch-shut/bin/ups-shu
1月 24 23:36:04 rpi1-disk startup-1st.sh[28546]: Hello world ['/opt/UPS-Watch-shut/bin/ups-shu
1月 24 23:36:05 rpi1-disk startup-1st.sh[28546]: Hello world ['/opt/UPS-Watch-shut/bin/ups-shu
1月 24 23:36:05 rpi1-disk systemd[1]: Stopping UPS Watching AutoRun...
1月 24 23:36:05 rpi1-disk systemd[1]: Stopped UPS Watching AutoRun.

Active: の行が Active: inactive (dead) になり、プログラムは停止していることが確認できます。

システム再起動による自動起動の確認

いよいよ待望の Linux の立上げによる自動起動の確認になります。ノートPCを再起動してステータスを確認します。

$ sudo systemctl status ups-watching.service
 ups-watching.service - UPS Watching AutoRun
Loaded: loaded (/etc/systemd/system/ups-watching.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2019-01-24 23:50:23 JST; 3min 43s ago
Main PID: 374 (python)
CGroup: /system.slice/ups-watching.service
└─374 python /opt/UPS-Watch-shut/bin/ups-shutdown.py

1月 24 23:53:57 rpi1-disk startup-1st.sh[374]: Hello world ['/opt/UPS-Watch-shut/bin/ups-shutd
1月 24 23:53:58 rpi1-disk startup-1st.sh[374]: Hello world ['/opt/UPS-Watch-shut/bin/ups-shutd
1月 24 23:53:59 rpi1-disk startup-1st.sh[374]: Hello world ['/opt/UPS-Watch-shut/bin/ups-shutd
1月 24 23:54:00 rpi1-disk startup-1st.sh[374]: Hello world ['/opt/UPS-Watch-shut/bin/ups-shutd
1月 24 23:54:01 rpi1-disk startup-1st.sh[374]: Hello world ['/opt/UPS-Watch-shut/bin/ups-shutd
1月 24 23:54:02 rpi1-disk startup-1st.sh[374]: Hello world ['/opt/UPS-Watch-shut/bin/ups-shutd
1月 24 23:54:03 rpi1-disk startup-1st.sh[374]: Hello world ['/opt/UPS-Watch-shut/bin/ups-shutd

問題なく起動されているようです


本題のUPSバッテリー監視とシャットダウン

システムの起動で一緒に監視プログラムを立上げることが可能なのを確認できました。

シャットダウンプログラム

提供されていた python のサンプルプログラムに少し手を加えて、単体ではシャットダウンが行われることを確認できました。これを起動されることを確認したサンプルと同じ名称 ups-shutdown.py で作成して置き換えます。それとバッテリー情報収集用のライブラリ raspiupshat.so を同じ場所に配置します。

$ cat /opt/UPS-Watch-shut/bin/ups-shutdown.py
#!/usr/bin/env python

# Raspi UPS Hat

# We only provide 2 interface to get battery information;
#
#Interface 1:
#Function: get current battery voltage
#Return value: battery voltage;
#float getv();

#Interface 2:
#Function:    get battery capacity
#Return value: 0~100+
#float getsoc();
#

import sys
# import Raspi UPS Hat library
import raspiupshat
import os
import time
import datetime

# init Raspi UPS Hat
raspiupshat.init();

# Get info
now = datetime.datetime.now()
print("{0:%Y-%m-%d %H:%M:%S} ; ".format(now) + "Voltage:%5.2fV ; Battery:%5i%%" % (raspiupshat.getv(), raspiupshat.getsoc()))

if raspiupshat.getsoc() >= 100:
        print "Battery FULL"
if raspiupshat.getsoc() < 20:
        print "Battery LOW"
while 1:
        if raspiupshat.getsoc() < 5:
                print "System will shutdown now,bye!"
                os.system("sudo shutdown -h 0")  
        # now = datetime.datetime.now()
        # print("{0:%H:%M:%S} ; ".format(now) + "Voltage:%5.2fV ; Battery:%5i%%" % (raspiupshat.getv(), raspiupshat.getsoc()))
        # time.sleep(10)

無限ループ内の最後の3行は、確認時に10秒毎に時間とバッテリー電圧値、バッテリー容量を表示するためのものです。必要なら先頭のコメント ‘#’ を消すことで表示できます。

起動の確認サンプルから監視プログラムへ置き換えと検証

次にユニットファイルを修正して、サンプルからバックアッププログラムに置き換えて、コマンドで実行してステータスを確認してみます。

$ ls -l /opt/UPS-Watch-shut/bin/
-rw-r--r-- 1 root root 7416 1月 25 11:07 raspiupshat.so
-rwxr-xr-x 1 root root   76 1月 24 22:49 startup-1st.sh
-rwxr-xr-x 1 root root  987 1月 25 11:06 ups-shutdown.py

$ sudo systemctl stop ups-watching.service
$ sudo systemctl daemon-reload
$ sudo systemctl start ups-watching.service
$ sudo systemctl status ups-watching.service
 ups-watching.service - UPS Watching AutoRun
Loaded: loaded (/etc/systemd/system/ups-watching.service; enabled; vendor preset: enabled)
Active: active (running) since Sat 2019-01-26 08:57:28 JST; 5h 36min ago
Main PID: 367 (python)
CGroup: /system.slice/ups-watching.service
└─367 python /opt/UPS-Watch-shut/bin/ups-shutdown.py

1月 26 14:32:48 rpi1-disk startup-1st.sh[367]: 14:31:08 ; Voltage: 4.34V ; Battery: 100%
1月 26 14:32:48 rpi1-disk startup-1st.sh[367]: 14:31:18 ; Voltage: 4.35V ; Battery: 100%
1月 26 14:32:48 rpi1-disk startup-1st.sh[367]: 14:31:28 ; Voltage: 4.35V ; Battery: 100%
1月 26 14:32:48 rpi1-disk startup-1st.sh[367]: 14:31:38 ; Voltage: 4.35V ; Battery: 100%
1月 26 14:32:48 rpi1-disk startup-1st.sh[367]: 14:31:48 ; Voltage: 4.35V ; Battery: 100%
1月 26 14:32:48 rpi1-disk startup-1st.sh[367]: 14:31:58 ; Voltage: 4.35V ; Battery: 100%
1月 26 14:32:48 rpi1-disk startup-1st.sh[367]: 14:32:08 ; Voltage: 4.35V ; Battery: 100%
1月 26 14:32:48 rpi1-disk startup-1st.sh[367]: 14:32:18 ; Voltage: 4.35V ; Battery: 100%
1月 26 14:32:48 rpi1-disk startup-1st.sh[367]: 14:32:28 ; Voltage: 4.35V ; Battery: 100%

上記の結果では、実際に shutdown 動作を行う python のプログラムに置き換えましたが、その中にコメントで記述している部分 ‘#’ のコメントを取り除き、メッセージ書き出しのステートメントを有効にし組込みました。

systemd の動作に不慣れで、正しく理解できていないのですが、systemctl status コマンドでは、処理中で書き出されたメッセージが直接表示されているわけではないようで、別に journalctl -u コマンドで表示できるようです。

書き出されたメッセージが、キューかバッファのような所に蓄積されていて、 systemctl status の実行時に移されて、journalctl -u で見られる場所に蓄積していくような感じです。そのため、最新の情報を確認するためには、systemctl status を先に実行してから journalctl -u を実行して確認する必要があるようです。

メッセージの各行先頭には、systemctl status で移された日時が記述されているようで、前回の確認から今回新しく加えられた行を判別することが可能なようです。なお、操作方法は less コマンドの操作と同じなので、‘/’ で文字列を検索したり、行をスキップしたり、‘1G’ で先頭行に移動したり、‘G’ で最終行に移動することもでき、上下の矢印キーで前後にメッセージを辿ることができます。

実際の動作検証作業

本番でのシステム終了動作を確認するために、ssh でリモート接続したまま、バッテリーの情報を 10 秒毎に表示して確認しましたが、5% になった後の1分後くらいにセッション切断のメッセージと共に、4% を表示して停止していました。

期待したシステム終了が行われているようで一安心です。メッセージが蓄積されている journalctl -u コマンドの結果例を次に示します。このコマンドは一般ユーザーで確認できるようです。

$ journalctl -u ups-watching.service

 1月 26 08:57:28 rpi1-disk systemd[1]: Started UPS Watching AutoRun.
 1月 26 09:14:56 rpi1-disk startup-1st.sh[367]: 2019-01-26 08:57:32 ; Voltage: 3.77V ; Battery:
 1月 26 09:14:56 rpi1-disk startup-1st.sh[367]: Battery LOW
 1月 26 09:14:56 rpi1-disk startup-1st.sh[367]: 08:57:32 ; Voltage: 3.77V ; Battery:    5%
 1月 26 09:14:56 rpi1-disk startup-1st.sh[367]: 08:57:42 ; Voltage: 3.78V ; Battery:    5%
 1月 26 09:14:56 rpi1-disk startup-1st.sh[367]: 08:57:52 ; Voltage: 3.77V ; Battery:    5%
 1月 26 09:14:56 rpi1-disk startup-1st.sh[367]: 08:59:54 ; Voltage: 3.77V ; Battery:    5%
 1月 26 09:14:56 rpi1-disk startup-1st.sh[367]: 09:00:04 ; Voltage: 3.77V ; Battery:    5%
 1月 26 09:14:56 rpi1-disk startup-1st.sh[367]: 09:00:14 ; Voltage: 3.78V ; Battery:    6%
 1月 26 09:14:56 rpi1-disk startup-1st.sh[367]: 09:00:24 ; Voltage: 3.78V ; Battery:    6%
 1月 26 09:14:56 rpi1-disk startup-1st.sh[367]: 09:00:34 ; Voltage: 3.78V ; Battery:    6%
 1月 26 09:14:56 rpi1-disk startup-1st.sh[367]: 09:00:44 ; Voltage: 3.78V ; Battery:    6%
 1月 26 09:14:56 rpi1-disk startup-1st.sh[367]: 09:00:54 ; Voltage: 3.78V ; Battery:    6%
 1月 26 09:14:56 rpi1-disk startup-1st.sh[367]: 09:01:05 ; Voltage: 3.78V ; Battery:    6%
 1月 26 09:14:56 rpi1-disk startup-1st.sh[367]: 09:01:15 ; Voltage: 3.78V ; Battery:    6%
 1月 26 09:14:56 rpi1-disk startup-1st.sh[367]: 09:01:25 ; Voltage: 3.78V ; Battery:    6%
 1月 26 09:14:56 rpi1-disk startup-1st.sh[367]: 09:01:35 ; Voltage: 3.78V ; Battery:    6%
 1月 26 09:14:56 rpi1-disk startup-1st.sh[367]: 09:01:45 ; Voltage: 3.78V ; Battery:    6%
 1月 26 09:14:56 rpi1-disk startup-1st.sh[367]: 09:01:55 ; Voltage: 3.78V ; Battery:    6%
 1月 26 09:14:56 rpi1-disk startup-1st.sh[367]: 09:02:05 ; Voltage: 3.78V ; Battery:    7%
 1月 26 09:14:56 rpi1-disk startup-1st.sh[367]: 09:02:15 ; Voltage: 3.78V ; Battery:    7%
lines 1-22

今回のUPSバッテリー監視と shutdown では、特にプログラムやサービスについての依存関係は無いので、これで完了です。

今後の改良としては、不要なメッセージの停止と、例えば容量が 10% 減少したら日時とバッテリー電圧や容量を記録しておいたり、50% を下回って 10% 減少する毎に携帯電話にメールを飛ばすとかしてみたいと考えています。

メールについては、ちょっと対策方法が重たくて、簡単に実現できるのかの目処が立っていません。

ラズパイで共有サーバー

前回で記述している初期のラズパイ1B+に、デスクトップ用のOS Raspbianをセットアップして、バッテリーバックアップモジュールと2.5インチHDDを組合せて、ネットワーク共有サーバーとして立上げます。

ラズパイも一気に普及したために、皆さんラズパイで色々な物を作っていますが、私には余裕がないので、昔から定番であるディスク容量に少し余裕を持たせたNASを作って、利用しようと思っています。

ディスク容量は 2TBです。割引で購入しましたが、安くなったものです。ラズパイの不満としてはディスクのIOインタフェースが、USBで少し遅く単体構成でRAID2のミラー化は無理っぽいですよね。

立上げのブートは仕方無く公開されている microSD ですが、システムとしてのルートパーティション以降はディスク内に配置して処理します。

ディスクはパーティション分割して、システムの置かれるルートパーティションは適度な大きさ30GBで、同様にスワップも適度に確保して、それ以外を300GB程度の複数に分割して、立上げ時に自動マウントしています。

NASとしてのデータをバックアップする方法としては、ディスクのミラーに代わる方法として、夜中から明方に毎日他のサーバーにコピーする方法で確保します。

初期システムとしては、デスクトップ用として立上げましたが、sshでリモート操作できるのを確認できてから、モニタのHDMIケーブル、キーボードとマウスのUSBケーブルを取り去りました。

今まで共有サーバーとして使用しているサーバーを継続で使用すれば、何も苦労は要らないと思うのですが、実は先日システムを構成しているケーブルに接触したらしく、システムがダウンしていて気が付かないまま数日置かれたことがありました。

そんな訳で、バッテリーバックアップを含めて安定したサーバーを作りたいと考えてます。新旧サーバー間でデータをコピーして置き換える準備をしています。

少し触れたり触っても停止しないように、ケースで覆う必要があり、安くて良さそうな物を百均セリエで見付けてきました。安っぽいですがこれで十分です。

バッテリーに電源供給するケーブルイーサネットケーブルの2本のケーブルだけが出ていて、バッテリーからの電源供給と遮断を行うマイクロスイッチにアクセスできる小さな穴を開けました。

ラズパイの進化は早くて凄い

何となくAmazonを見ていたら、ラズパイにバッテリーで供給できるキットが出ていたので購入しました。

ネット上には、そのキットに関する情報の公式ブログが立上げられているようで、ラズパイへの電源供給を制御できる小さなプッシュスイッチがあることもわかりました。

日本国内で最初に発売されたラズパイ1Bでは、ボード固定用のネジ穴位置がユニーク過ぎて、このキットとは親和性が良くないと思われるので、1B+と組合せて共有サーバーとして立上げることにしました。

ラズパイ公式OSのRaspbianの選択ですが、本家のページを見ると3種類あるようで、色々詰込んだデスクトップ用基本のデスクトップ用、サーバー用途だと思われる最小構成、過去にデスクトップ用では痛い経験があるものの、今回は基本のデスクトップ用で作ってみようと決めました。

2018-11-13 / 4.14 / Raspbian stretch with desktop です。ダウンロードして展開しながら、microSDに書込みました。作業はLinux上なので、パイプで繋いだ1行のコマンド例が出ていたので、それを参考に作業しました。

microSDラズパイ1B+に挿入して、バッテリー供給キットの充電が途中なのが、LEDランプの点滅位置でわかります。

ラズパイ1B+には、USBポートが4つあります。USB接続のマウスとキーボードを用意し接続して、HDMIケーブルをテレビのモニターに繋ぎ、バッテリー供給キットのスイッチでラズパイに電源供給しました。

立上りが遅いので心配にはなりますが、暫く待つとデスクトップ画面が表示され、そのまま見ていると勝手にダイアログが表示され、microSDの空き一杯にエリアを拡張しているようです。

その後も必要な設定が自動的に起動され、パスワード変更ロケーションの設定が行われました。久し振りに触れましたが凄い変化です。今迄の経験では日本語化で苦労していましたが、ちょっと選択をしただけで、日本語化が完了して、漢字入力もできてしまいました。

驚きの連続です。最後の安定までは時間が掛かりますが、アップデートも最新になっているし、時間も日本時間になっていて、再起動後の立上げ直後にも日本時間になっていて、セットアップの進化に感服しました。

久し振りにラズベリーパイ

いつかは忘れたけど、家のネットに共有サーバーとして立上げたラズパイ3Bが、安定稼働数カ月の後に勝手にシステムアップデートして、危篤になり脳死の植物状態になってしまいました。

サーバー用途に、デスクトップを含むフルセットのRaspbianで、セットアップしたのが悪かったのかと反省してます。

そのラズパイ3Bは、共有サーバーとして利用途中でも、何度か同様のアップデートが行われ、止まっても後から介入して、何度かは元気に立ち直らせていたのです。

最後の時は、思い付く色々な手を尽くしても駄目でした。それ以来、不安定なラズパイは実運用に向かないと考えて、そのラズパイ3Bを放置してました。

その後、仕方なく手持ちの初期の頃の古くて遅いラズパイ1Bに、最小構成のRaspbianを入れて共有サーバーとしてセットアップしました。

別な場所で、ラズパイ2Bに同じ最小構成のRaspbianを入れて、夜間に共有サーバーのデータを自動でバックアップするサーバーとして立上げました。

こちらは安定して動作しています。自動でシステムアップデートは行われませんが、時々思い出したように手動でアップデートしてます。対象のアップデートは全て適用してますが、今まで問題は起きていません。

初期の遅いラズパイでも、共有サーバーとして稼働しているだけなら何のストレスも感じません。外付けディスクから直接立上げる方法は公開されていないので、最初にSDmicroSDで立上げて、外付けディスクに移る方法で利用してます。

ネット共有サーバーとしてmp4の動画も入れて、スマホやパソコンから再生してますが、特に高画質の大きな動画ではないので、問題なく利用できています。

そうは言っても、初期のラズパイの1Bは、USBバスパワーで外付けディスクを稼働させるのは不可能で、セルフパワーのHUBや電源を必要とするため、色々と煩雑で100均のケースに入れてますが、近くの配置を変えていた時に触れたのかシステムダウンしてました。

そんな事もあり、ラズパイB+に、UPSとして利用できそうなバッテリーを含むオプションとかを組合せて、外付けディスクの容量も倍にして共有サーバーを置き換えようかと考えてます。

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

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

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

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

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

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

Linux 立上げ時の自動起動

最近も日常に追われすぎていて、何をやっても中途半端に中断してしまい、続きがいつになるか分からない日々が続いています。

今回の作業背景

PCを利用していて痛い目に何度も遭っている経験から、今最重要課題と捉えているのが、作業結果を意識しないでできるバックアップ環境を作ることだと考えています。私は普段使いの Linux (Ubuntu) をセットアップしているノートPCを日常で利用しているのですが、その中で作業した内容はある程度無意識で定期的に共有サーバーにバックアップしています。

そのバックアップ方法は、単純な方法で cron を利用して rsync コマンドで、定期間隔の非同期でネットワークサーバーに転送する方法で実現しています。転送されたサーバーからは更に1日1回の頻度て他のサーバーにもコピーしています。

常にバックアップしているのに、では何が問題なのか、実は普段利用することも少ない Windows系 OSもデュアルブートできる環境で、Linux で実現できていない一部のアプリを利用することも時にはあります。その中で作業した内容については適切なバックアップができないでいます。意識してコピーする方法なら今でも面倒な作業として出来るのですが、無意識でバックアップして欲しいのが本音です。

そこで壁に当たりました。自動的に Windows パーティションをバックアップするには、

  • Windows を操作しているタイミングでの自動バックアップ
  • Linux で操作しているタイミングでの自動バックアップ

普段の利用は、Linux なので、負荷増になる無用なバックアッププロセスが常時稼働するのは避けたいので、Windows から Linux に切り替えるタイミングでの実行が理想だろうと考えて、過去の定番な方法 SysV init 立上げプロセスでの rc.local を模索したのですが、システム立上げ時に実行することが出来ないようです。機能しないのかタイミングでエラーしているのかは不明です。

最近の Linux システムは、立上げ時の方法が従来の SysV init から systemd に変わっているようで、私のノートPCも変わっているような気がします。そこで試行錯誤してみることにしました。

参考にしたサイトは、作り方を事細かく説明してくれています。


ここからが作業の試行錯誤の本題

実行したことをすぐに忘れる自分のための備忘録です。

Linux 起動時に、一度だけ Windows パーティションの一部を共有サーバーにバックアップする。Linux 立上げ前に Windows を利用していたかは問題外として、バックアップを実行したタイムスタンプをバックアップエリア内に残しておくこととします。

実際の組込み前に、参考にしたサイトの手順を自分の学習と動作確認のために実行してみることから始めます。他の情報の説明によると systemd に登録するサービスの指示書をユニットファイルと呼んでいるようです。

パッケージ名: NoteStartUpRun で、ユニットファイル名: note-startup-1st.service としてみました。何かちょっとネーミングがおかしいかなとも思いますが、私の頭の中では最初に実行する処理なので -1st を付けてみました。まぁただの名前なのでここから始めます。

サービス(ユニットファイル)の登録は、 /etc/systemd/system/note-startup-1st.service になるようで、この中には登録するサービスの情報を決められた書式で記述するようです。

そして実際に動作させるプログラムは、パッケージ名で管理するディレクトリに記述するようですが、 /opt/NoteStartUpRun/bin となっていて、一般的な実行形式のコマンドを入れる bin に集めているようです。そこで疑問ですが、パッケージディレクトリには、bin 以外に本来は何が置かれているのでしょう…深く考えないで進めます。

systemd の動作を確認する雛形作り

参考サイトがカレントで作成して、それを該当するディレクトリにコピーして、所有者を root に変更したり、アクセス権の変更をしているので、私もその方法を踏襲します。

$ vi note-startup-1st.service
[Unit] 
Description = Note Private AutoRun
After=network-online.target remote-fs.target nss-lookup.target
ConditionPathExists=/opt/NoteStartUpRun/bin

[Service]
ExecStart=/opt/NoteStartUpRun/bin/note-stup-1st.sh
Restart=no
Type=simple

[Install]
WantedBy=multi-user.target

$ sudo cp note-startup-1st.service /etc/systemd/system
$ sudo chown root:root /etc/systemd/system/note-startup-1st.service
$ sudo chmod 644 /etc/systemd/system/note-startup-1st.service
$ vi note-stup-1st.sh
#!/bin/sh
exec /usr/bin/env python /opt/NoteStartUpRun/bin/Python-Sample.py

$ sudo mkdir -p /opt/NoteStartUpRun/bin
$ sudo chmod 755 /opt/NoteStartUpRun/bin
$ sudo cp note-stup-1st.sh /opt/NoteStartUpRun/bin
$ sudo chown root:root /opt/NoteStartUpRun/bin/note-stup-1st.sh
$ sudo chmod 755 /opt/NoteStartUpRun/bin/note-stup-1st.sh

実際に動作するサンプルプログラム

最終的に起動されるサンプルプログラムは、bash や ruby または python でも構わないのでしょうけど、参考サイトにある例をそのまま丸コピーしてきました。検証作業の説明も丁寧に行われているので、見比べるのにも最適なので利用させて頂いています。例では python で組まれた1秒毎にメッセージを書き出す無限ループの処理で、Python-Sample.py として、次の記述です。

$ vi Python-Sample.py
#!/usr/bin/env python
import sys
from time import sleep
if __name__ == '__main__':
  while True:
    print "Hello world %s" % (sys.argv)
    sys.stdout.flush()
    sleep(1)

$ sudo cp Python-Sample.py /opt/NoteStartUpRun/bin
$ sudo chown root:root /opt/NoteStartUpRun/bin/Python-Sample.py
$ sudo chmod 755 /opt/NoteStartUpRun/bin/Python-Sample.py 

サービスとして定義している note-startup-1st.service により note-stup-1st.sh が起動されます。その中で単純にサンプルプログラムの Python-Sample.py を起動しています。

作成したユニットファイルやサンプルプログラムの確認

作成したユニットファイルやパッケージ内のプログラムの所有者とアクセス権の確認をしておきます。

$ ls -l /opt/NoteStartUpRun
合計 4
drwxr-xr-x 2 root root 4096  1月  9 15:01 bin
$ ls -l /opt/NoteStartUpRun/bin
合計 8
-rwxr-xr-x 1 root root 175  1月  9 15:01 Python-Sample.py
-rwxr-xr-x 1 root root  77  1月  9 14:54 note-stup-1st.sh
$ ls -l /etc/systemd/system/note-startup-1st.service
-rw-r--r-- 1 root root 276  1月  9 14:41 /etc/systemd/system/note-startup-1st.service

茶色の部分の root ユーザーと 755 及び 644 が確認できました。

サンプルプログラムの単体動作検証

無限ループでメッセージを書き出すサンプルプログラムを単体で起動して、 [Ctrl+C] で強制停止して動作の確認をしておきます。

$ sudo /opt/NoteStartUpRun/bin/Python-Sample.py
Hello world ['/opt/NoteStartUpRun/bin/Python-Sample.py']
Hello world ['/opt/NoteStartUpRun/bin/Python-Sample.py']
Hello world ['/opt/NoteStartUpRun/bin/Python-Sample.py']
Hello world ['/opt/NoteStartUpRun/bin/Python-Sample.py']
Hello world ['/opt/NoteStartUpRun/bin/Python-Sample.py']
^CTraceback (most recent call last):
  File "/opt/NoteStartUpRun/bin/Python-Sample.py", line 8, in 
    sleep(1)
KeyboardInterrupt

単体では問題なくメッセージが書き出されるようです。


ユニットファイルを systemd に登録

ここからは、systemd へのサービス(ユニットファイル)の登録と検証作業になるようです。ユニットファイル等を追加や変更した後には、必ず次のコマンド sudo systemctl daemon-reload を実行します。

そして一緒にステータスも確認しておきます。

$ sudo systemctl daemon-reload
$ sudo systemctl status note-startup-1st.service
● note-startup-1st.service - Note Private AutoRun
   Loaded: loaded (/etc/systemd/system/note-startup-1st.service; disabled; vendor preset: enabled)
   Active: inactive (dead)

ステータスで表示される Loaded: 行のカッコ内の1つ目と2つ目のセミコロンの間の disabled となっているのは、自動起動が無効になっているということのようで、自動起動できるように設定します。

自動起動が行われるように設定

$ sudo systemctl enable note-startup-1st.service
Created symlink from /etc/systemd/system/multi-user.target.wants/note-startup-1st.service to /etc/systemd/system/note-startup-1st.service.
$ sudo systemctl status note-startup-1st.service
● note-startup-1st.service - Note Private AutoRun
   Loaded: loaded (/etc/systemd/system/note-startup-1st.service; enabled; vendor preset: enabled)
   Active: inactive (dead)

ユニットファイルの定義内に、[ Install ] の WantedBy= で定義しているユニットにリンクが張られ、先ほどの /etc/systemd/system/note-startup-1st.service; の後の disabledenabled に変わっています。

これで再立ち上げで自動実行されるようになっているはずですが、その前にコマンドで起動して確認したり、停止させる操作をして動作を確認します。

systemd の手動起動と停止の確認

ユニットファイル名を指定したコマンド sudo systemctl start note-startup-1st.service で起動できます。

$ sudo systemctl start note-startup-1st.service
$ sudo systemctl status note-startup-1st.service
note-startup-1st.service - Note Private AutoRun
   Loaded: loaded (/etc/systemd/system/note-startup-1st.service; enabled; vendor preset: enabled)
   Active: active (running) since 火 2018-01-09 15:13:41 JST; 12s ago
 Main PID: 7997 (python)
   CGroup: /system.slice/note-startup-1st.service
           └─7997 python /opt/NoteStartUpRun/bin/Python-Sample.py

 1月 09 15:13:44 MITA-NY40S note-stup-1st.sh[7997]: Hello world ['/opt/NoteStartUpRun/bin/Python-S
 1月 09 15:13:45 MITA-NY40S note-stup-1st.sh[7997]: Hello world ['/opt/NoteStartUpRun/bin/Python-S
 1月 09 15:13:46 MITA-NY40S note-stup-1st.sh[7997]: Hello world ['/opt/NoteStartUpRun/bin/Python-S
 1月 09 15:13:47 MITA-NY40S note-stup-1st.sh[7997]: Hello world ['/opt/NoteStartUpRun/bin/Python-S

起動されて1秒毎にメッセージが書きだされているのが確認できます。

次は、sudo systemctl stop note-startup-1st.service コマンドで停止して結果をステータスで確認してみます。

$ sudo systemctl stop note-startup-1st.service
$ sudo systemctl status note-startup-1st.service
note-startup-1st.service - Note Private AutoRun
   Loaded: loaded (/etc/systemd/system/note-startup-1st.service; enabled; vendor preset: enabled)
   Active: inactive (dead) since 火 2018-01-09 15:14:44 JST; 4min 47s ago
  Process: 7997 ExecStart=/opt/NoteStartUpRun/bin/note-stup-1st.sh (code=killed, signal=TERM)
 Main PID: 7997 (code=killed, signal=TERM)

 1月 09 15:14:37 MITA-NY40S note-stup-1st.sh[7997]: Hello world ['/opt/NoteStartUpRun/bin/Python-S
 1月 09 15:14:38 MITA-NY40S note-stup-1st.sh[7997]: Hello world ['/opt/NoteStartUpRun/bin/Python-S
 1月 09 15:14:39 MITA-NY40S note-stup-1st.sh[7997]: Hello world ['/opt/NoteStartUpRun/bin/Python-S
 1月 09 15:14:40 MITA-NY40S note-stup-1st.sh[7997]: Hello world ['/opt/NoteStartUpRun/bin/Python-S
 1月 09 15:14:41 MITA-NY40S note-stup-1st.sh[7997]: Hello world ['/opt/NoteStartUpRun/bin/Python-S
 1月 09 15:14:42 MITA-NY40S note-stup-1st.sh[7997]: Hello world ['/opt/NoteStartUpRun/bin/Python-S
 1月 09 15:14:43 MITA-NY40S note-stup-1st.sh[7997]: Hello world ['/opt/NoteStartUpRun/bin/Python-S
 1月 09 15:14:44 MITA-NY40S note-stup-1st.sh[7997]: Hello world ['/opt/NoteStartUpRun/bin/Python-S
 1月 09 15:14:44 MITA-NY40S systemd[1]: Stopping Note Private AutoRun...
 1月 09 15:14:44 MITA-NY40S systemd[1]: Stopped Note Private AutoRun.

Active: の行が Active: inactive (dead) になり、プログラムは停止していることが確認できます。

一般ユーザーでジャーナルを確認

次にプログラムの出力ログを確認できる journalctl コマンドがあるとの説明なので試してみます。

$ journalctl -u note-startup-1st.service
-- Logs begin at 月 2018-01-08 19:44:01 JST, end at 火 2018-01-09 15:21:01 JST. --
 1月 09 15:13:41 MITA-NY40S systemd[1]: Started Note Private AutoRun.
 1月 09 15:13:42 MITA-NY40S note-stup-1st.sh[7997]: Hello world ['/opt/NoteStartUpRun/bin/Python-S
 1月 09 15:13:43 MITA-NY40S note-stup-1st.sh[7997]: Hello world ['/opt/NoteStartUpRun/bin/Python-S
 1月 09 15:13:44 MITA-NY40S note-stup-1st.sh[7997]: Hello world ['/opt/NoteStartUpRun/bin/Python-S

システム再起動による自動起動の確認

いよいよ待望の Linux の立上げによる自動起動の確認になります。ノートPCを再起動してステータスを確認します。

$ sudo systemctl status note-startup-1st.service
note-startup-1st.service - Note Private AutoRun
   Loaded: loaded (/etc/systemd/system/note-startup-1st.service; enabled; vendor preset: enabled)
   Active: active (running) since 火 2018-01-09 15:45:33 JST; 3min 15s ago
 Main PID: 1079 (python)
   CGroup: /system.slice/note-startup-1st.service
           └─1079 python /opt/NoteStartUpRun/bin/Python-Sample.py

 1月 09 15:48:38 MITA-NY40S note-stup-1st.sh[1079]: Hello world ['/opt/NoteStartUpRun/bin/Python-S
 1月 09 15:48:39 MITA-NY40S note-stup-1st.sh[1079]: Hello world ['/opt/NoteStartUpRun/bin/Python-S
 1月 09 15:48:40 MITA-NY40S note-stup-1st.sh[1079]: Hello world ['/opt/NoteStartUpRun/bin/Python-S
 1月 09 15:48:41 MITA-NY40S note-stup-1st.sh[1079]: Hello world ['/opt/NoteStartUpRun/bin/Python-S
 1月 09 15:48:42 MITA-NY40S note-stup-1st.sh[1079]: Hello world ['/opt/NoteStartUpRun/bin/Python-S
 1月 09 15:48:43 MITA-NY40S note-stup-1st.sh[1079]: Hello world ['/opt/NoteStartUpRun/bin/Python-S
 1月 09 15:48:44 MITA-NY40S note-stup-1st.sh[1079]: Hello world ['/opt/NoteStartUpRun/bin/Python-S
 1月 09 15:48:45 MITA-NY40S note-stup-1st.sh[1079]: Hello world ['/opt/NoteStartUpRun/bin/Python-S
 1月 09 15:48:46 MITA-NY40S note-stup-1st.sh[1079]: Hello world ['/opt/NoteStartUpRun/bin/Python-S
 1月 09 15:48:47 MITA-NY40S note-stup-1st.sh[1079]: Hello world ['/opt/NoteStartUpRun/bin/Python-S

問題なく起動されているようです。

その他の動作確認ツールを学習

今は直接必要がないのですが、参考サイトの説明では、実行時の 標準入力・標準出力・エラー出力 が、どこに繋がっているのか確認できるとのことですので今後のためにも試してみます。

上記出力からプロセスIDは、 1079 (PID: 1079) です。

$ sudo ls -l /proc/1079/fd
合計 0
lr-x------ 1 root root 64  1月  9 15:45 0 -> /dev/null
lrwx------ 1 root root 64  1月  9 15:45 1 -> socket:[21758]
lrwx------ 1 root root 64  1月  9 15:45 2 -> socket:[21758]

標準入力は、ダミーデバイスの /dev/null に割り当てられ、標準出力とエラー出力は共に UNIXドメインソケットに接続されているようです。参考サイトのコマンドもそのまま試してみます。

$ sudo ss -x -p|grep 21758
u_str  ESTAB      0      0       * 21758                 * 20776                 users:(("python",pid=1079,fd=2),("python",pid=1079,fd=1))
u_str  ESTAB      0      0      /run/systemd/journal/stdout 20776                 * 21758                 users:(("systemd-journal",pid=212,fd=38),("systemd",pid=1,fd=74))

知識がないので私には細かいことはわかりませんが、 systemd-journal が以前利用されていた syslogd を置き換えたログシステムとの説明があります。

systemd に関する説明資料

systemd に関しての説明がネット上の RedHat のサイトにありましたのでリンクをしておきます。


本題のシステム起動時のバックアップ

やっと自分で行いたい目的であるシステム立上げ時の自動バックアップ、の一歩手前まで辿りつけました。昔操作していた Windows システムも含めて自分で考えたサービスを追加して自動実行した経験はないので、何か少しワクワクした気持ちになります。

バックアッププログラムの雛形

パイソンのサンプルプログラムを置き換える実際のバックアッププログラムは、シェルスクリプトで記述した単純なもので、 Windows パーティションを一時マウントし、その一部のデータをリモートサーバーの特定のパスに rsync コマンドでコピーするものです。変更があった部分だけがコピーされるのですが、実行時のタイムスタンプを残すように少しだけ細工を追加しています。

$ cat /opt/NoteStartUpRun/bin/sunao-note_Windows-Documents-bkup
#!/bin/bash

server='192.168.x.21'                    # バックアップ先サーバー

bkup_D="$server:/home/bkup/sunao-Win-Doc/"   # バックアップ先 リモートサーバー

mntS='/mnt/ntfs'
bkup_S="$mntS/Users/sunao/Documents/"      # バックアップ元のベース

/bin/mount $mntS
echo "実行タイムスタンプ  `date`" > $bkup_S/TimeStamp.txt
/usr/bin/rsync -av --delete $bkup_S $bkup_D
/bin/umount $mntS

パイソンのサンプルと同じディレクトリにコピーされ、所有者とアクセス権の設定も確認して、単体動作では問題なくバックアップできています。

サンプルからバックアッププログラムへ置き換えと検証

次にユニットファイルを修正して、サンプルからバックアッププログラムに置き換えて、コマンドで実行してステータスを確認してみます。

$ sudo vi /opt/NoteStartUpRun/bin/note-stup-1st.sh
#!/bin/sh
exec /opt/NoteStartUpRun/bin/sunao-note_Windows-Documents-bkup 

$ sudo systemctl daemon-reload
$ sudo systemctl start note-startup-1st.service
$ sudo systemctl status note-startup-1st.service
● note-startup-1st.service - Note Private AutoRun
   Loaded: loaded (/etc/systemd/system/note-startup-1st.service; enabled; vendor preset: enabled)
   Active: inactive (dead) since 火 2018-01-09 16:13:53 JST; 26s ago
  Process: 3440 ExecStart=/opt/NoteStartUpRun/bin/note-stup-1st.sh (code=exited, status=0/SUCCESS)
 Main PID: 3440 (code=exited, status=0/SUCCESS)

 1月 09 16:13:51 MITA-NY40S ntfs-3g[3457]: Version 2015.3.14AR.1 integrated FUSE 28
 1月 09 16:13:51 MITA-NY40S ntfs-3g[3457]: Mounted /dev/sda4 (Read-Write, label "Windows", NTFS 3.
 1月 09 16:13:51 MITA-NY40S ntfs-3g[3457]: Cmdline options: rw,noexec,nosuid,nodev,uid=1000,gid=10
 1月 09 16:13:51 MITA-NY40S ntfs-3g[3457]: Mount options: rw,noexec,nosuid,nodev,user,allow_other,
 1月 09 16:13:51 MITA-NY40S ntfs-3g[3457]: Global ownership and permissions enforced, configuratio
 1月 09 16:13:53 MITA-NY40S note-stup-1st.sh[3440]: sending incremental file list
 1月 09 16:13:53 MITA-NY40S note-stup-1st.sh[3440]: TimeStamp.txt
 1月 09 16:13:53 MITA-NY40S note-stup-1st.sh[3440]: sent 3,991 bytes  received 61 bytes  1,620.80 
 1月 09 16:13:53 MITA-NY40S note-stup-1st.sh[3440]: total size is 24,092,416  speedup is 5,945.81
 1月 09 16:13:53 MITA-NY40S ntfs-3g[3457]: Unmounting /dev/sda4 (Windows)
lines 1-16/16 (END)

コマンドによる起動では問題なく実行されて、正常終了しています。

実際の立上げによるバックアップの検証作業

本番でのシステム立上げによる実行の動作確認です。

ノートPC再起動後の journalctl コマンドによる結果が次のようになっています。

$ journalctl -u note-startup-1st.service

-- Logs begin at 火 2018-01-09 16:24:34 JST, end at 火 2018-01-09 16:27:17 JST. --
 1月 09 16:25:12 MITA-NY40S systemd[1]: Started Note Private AutoRun.
 1月 09 16:25:14 MITA-NY40S ntfs-3g[1071]: Version 2015.3.14AR.1 integrated FUSE 28
 1月 09 16:25:14 MITA-NY40S ntfs-3g[1071]: Mounted /dev/sda4 (Read-Write, label "Windows", NTFS 3.1)
 1月 09 16:25:14 MITA-NY40S ntfs-3g[1071]: Cmdline options: rw,noexec,nosuid,nodev,uid=1000,gid=1000,user
 1月 09 16:25:14 MITA-NY40S ntfs-3g[1071]: Mount options: rw,noexec,nosuid,nodev,user,allow_other,nonempty,relatime,default_permissi
 1月 09 16:25:14 MITA-NY40S ntfs-3g[1071]: Global ownership and permissions enforced, configuration type 7
 1月 09 16:25:16 MITA-NY40S note-stup-1st.sh[1039]: ssh: connect to host 192.168.x.21 port 22: Network is unreachable
 1月 09 16:25:16 MITA-NY40S note-stup-1st.sh[1039]: rsync: connection unexpectedly closed (0 bytes received so far) [sender]
 1月 09 16:25:16 MITA-NY40S note-stup-1st.sh[1039]: rsync error: unexplained error (code 255) at io.c(226) [sender=3.1.1]
 1月 09 16:25:16 MITA-NY40S ntfs-3g[1071]: Unmounting /dev/sda4 (Windows)

結果は残念ながらエラーしていてバックアップされない状況です。ユニットファイルの定義の中で、立上げプロセスの実行条件の After= で定義している箇所を色々と変更してみましたが効果がありませんでした。

最初は認証の sshd 等のプロセスが立上がっていないのが原因ではないかとか色々と試行錯誤しましたが、解決には至りませんでした。ネットワーク環境が立上がってから少し安定する時間が必要なのかもしれません。

systemd の依存関係を確認するツール

Systemdのサービスの依存関係を調べる方法 というサイトがありました。ここではグラフ形式にプロットして、ブラウザの Firefox で見る方法が説明されていてとても参考になりました。

最終的にバックアップできるように修正

最終的な修正は、立上げで特に早い段階でバックアップする必要もないので、ユニットファイルの After= に、立上げが一番遅いと思われる multi-user.target を指定して、バックアッププログラムが起動されてから実際のバックアップ動作が開始する前に 5分待つように sleep 300 を追加しました。

$ cat /etc/systemd/system/note-startup-1st.service

[Unit] 
Description = Note Private AutoRun
After=network-online.target multi-user.target
ConditionPathExists=/opt/NoteStartUpRun/bin

[Service]
ExecStart=/opt/NoteStartUpRun/bin/note-stup-1st.sh
Restart=no
Type=simple

[Install]
WantedBy=multi-user.target

$ cat /opt/NoteStartUpRun/bin/sunao-note_Windows-Documents-bkup
#!/bin/bash

server='192.168.x.21'                    # バックアップ先サーバー

bkup_D="$server:/home/bkup/sunao-Win-Doc/"  # バックアップ先位置

mntS='/mnt/ntfs'
bkup_S="$mntS/Users/sunao/Documents/"       # バックアップ元のベース

sleep 300           # 安定するように 5分待つ
/bin/mount $mntS
echo "実行タイムスタンプ  `date`" > $bkup_S/TimeStamp.txt
/usr/bin/rsync -av --delete $bkup_S $bkup_D
/bin/umount $mntS

待ち時間を追加する前は毎回エラーしていました。実際には、 sleep 180 の3分でもバックアップ動作は正常に行われていたのですが、余裕を持たせて sleep 300 にしています。

systemd ツールの利用結果

systemd の立上げ時間は、次のコマンドで表示され、 plot を付加して実行するとグラフ形式で svg ファィルを作成できるようで、ブラウザの Firefox で表示した最後の一部のみをここでは取り出しています。

$ systemd-analyze
Startup finished in 3.340s (firmware) + 7.713s (loader) + 6.703s (kernel) + 47.235s (userspace) = 1min 4.992s
$ systemd-analyze plot > startup.svg
$ firefox startup.svg

上記画像の右下角に、下から5番目に multi-user.target が表示され、その下に今回作成したバックアップ処理の note-startup-1st.service の表示がありますので、立上げプロセスの最終で起動されているのが確認できます。

なお立上げプロセスは、systemd-analyze コマンドの実行により、総計で約1分5秒程掛かっていることがわかります。その大半の 47秒を userspace が占めていることがわかります。

完成した立上げでのバックアップ

特に書き換えるデータがなく、実行時のタイムスタンプファイルのみがコピーされているだけの正常なバックアッププロセスを、最後にステータスとジャーナル表示の両方で載せておきます。

$ sudo systemctl status note-startup-1st.service
● note-startup-1st.service - Note Private AutoRun
   Loaded: loaded (/etc/systemd/system/note-startup-1st.service; enabled; vendor preset: enabl
   Active: inactive (dead) since 木 2018-01-11 19:50:00 JST; 11min ago
  Process: 1198 ExecStart=/opt/NoteStartUpRun/bin/note-stup-1st.sh (code=exited, status=0/SUCC
 Main PID: 1198 (code=exited, status=0/SUCCESS)

 1月 11 19:49:58 MITA-NY40S ntfs-3g[2846]: Version 2015.3.14AR.1 integrated FUSE 28
 1月 11 19:49:58 MITA-NY40S ntfs-3g[2846]: Mounted /dev/sda4 (Read-Write, label "Windows", NTF
 1月 11 19:49:58 MITA-NY40S ntfs-3g[2846]: Cmdline options: rw,noexec,nosuid,nodev,uid=1000,gi
 1月 11 19:49:58 MITA-NY40S ntfs-3g[2846]: Mount options: rw,noexec,nosuid,nodev,user,allow_ot
 1月 11 19:49:58 MITA-NY40S ntfs-3g[2846]: Global ownership and permissions enforced, configur
 1月 11 19:50:00 MITA-NY40S note-stup-1st.sh[1198]: sending incremental file list
 1月 11 19:50:00 MITA-NY40S note-stup-1st.sh[1198]: TimeStamp.txt
 1月 11 19:50:00 MITA-NY40S note-stup-1st.sh[1198]: sent 3,991 bytes  received 61 bytes  1,620
 1月 11 19:50:00 MITA-NY40S note-stup-1st.sh[1198]: total size is 24,092,416  speedup is 5,945
 1月 11 19:50:00 MITA-NY40S ntfs-3g[2846]: Unmounting /dev/sda4 (Windows)
lines 1-16/16 (END)
$ journalctl -u note-startup-1st.service
-- Logs begin at 木 2018-01-11 19:44:14 JST, end at 木 2018-01-11 19:50:53 JST. --
 1月 11 19:44:57 MITA-NY40S systemd[1]: Started Note Private AutoRun.
 1月 11 19:49:58 MITA-NY40S ntfs-3g[2846]: Version 2015.3.14AR.1 integrated FUSE 28
 1月 11 19:49:58 MITA-NY40S ntfs-3g[2846]: Mounted /dev/sda4 (Read-Write, label "Windows", NTF
 1月 11 19:49:58 MITA-NY40S ntfs-3g[2846]: Cmdline options: rw,noexec,nosuid,nodev,uid=1000,gi
 1月 11 19:49:58 MITA-NY40S ntfs-3g[2846]: Mount options: rw,noexec,nosuid,nodev,user,allow_ot
 1月 11 19:49:58 MITA-NY40S ntfs-3g[2846]: Global ownership and permissions enforced, configur
 1月 11 19:50:00 MITA-NY40S note-stup-1st.sh[1198]: sending incremental file list
 1月 11 19:50:00 MITA-NY40S note-stup-1st.sh[1198]: TimeStamp.txt
 1月 11 19:50:00 MITA-NY40S note-stup-1st.sh[1198]: sent 3,991 bytes  received 61 bytes  1,620
 1月 11 19:50:00 MITA-NY40S note-stup-1st.sh[1198]: total size is 24,092,416  speedup is 5,945
 1月 11 19:50:00 MITA-NY40S ntfs-3g[2846]: Unmounting /dev/sda4 (Windows)
lines 1-12/12 (END)

 

ラズパイ1B で共有サーバーの構築 (5/)

  1. リモートメンテに必須の byobu / screen の設定
  2. いよいよ念願の共有サーバー samba の設定

キーボードもモニタも無いサーバーを操作するには、他のパソコンからのリモートメンテナンスが必須ですが、操作も並行して同時に別のコマンドを実行させたいことはよくあることです。素のままだと ssh 等を複数起動してセッションを張らないと出来ません。また長く掛かるコマンドの実行中にセッションが切れたり、クライアント側を停止するとサーバー側もエラーで停止します。

過去の記事でこれらについての対策方法として、仮想端末について触れているので、その部分を見直しながらコピーしておきます。

仮想端末と呼ばれるジャンルには、 byobu / tmux / screen と言ったソフトがあって、byobu は tmux や screen のラッパープログラムとして機能します。

何が便利かと言うと、 ssh 等で直接リモートログインした状態で、サーバー側のコマンドを利用して処理を行っている時に、何かの要因で通信路に障害が起きてセッションが切れると、実行中の処理も異常終了してしまいます。しかし、これらの仮想端末を利用して処理していると仮に通信路で障害が発生しても、再接続するだけで元の処理は継続して実行したままなので途中の経過表示も含めて元の続きを継続できます。

メリットを言い換えると、時間のかかる処理をリモートサーバー上で起動しておいて、操作するクライアント側では電源を落とす等の方法で接続を切ってしまい、時々接続して途中経過を確認したり、時間を置いてから最終結果の確認だけを行うことも可能になります。それと、複数の ssh 接続が必要なことも時としてありますが、例えば速度が遅く不安定なインターネットを経由した先のサーバー接続等を考えた場合には、直接の接続セッションは単一なのに、複数の仮想端末内で色々な処理を並行して実行できるのは安心感があります。

そんな訳で byobu を導入します。一般的に byobu は通常 tmux を伴って仕事をするのですが、私の場合は昔から screen を利用していた経緯があって、他に設置のサーバーでも byobu と screen の組合せで稼働しています。

$ ssh 192.168.11.21    .....クライアントからのssh接続要求

Linux rpi1-com2 4.9.59+ #1047 Sun Oct 29 11:47:10 GMT 2017 armv6l

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Mon Nov 20 20:26:12 2017 from 192.168.11.43
$ byobu      .....リモート接続されたラズパイで byobu を起動

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.

Welcome to the light, powerful, text window manager, Byobu.
You can toggle the launch of Byobu at login with:
'byobu-disable' and 'byobu-enable'

For tips, tricks, and more information, see:
* http://bit.ly/byobu-help

$

 

 

 

 

 
              ...... F6 キーの押下で byobu 終了 ⇒ 起動前に戻る
[detached (from session 1)]

実際のデフォルトで起動した byobu の画面は次のイメージです。 byobu+tmux の形式です。

そして byobu の裏で screen が動作するように変更します。

$ byobu-select-backend
Select the byobu backend:
1. tmux
2. screen

Choose 1-2 [1]: 2

これで screen と連携した byobu の設定が完了しました。
byobu+screen のイメージは次の画面です。操作した感じでは問題なさそうです。

これらの仮想端末ソフトには、コマンド入力を受付けるシェル画面、例えば bashの画面が表示されていますが、そのまま文字を入力する以外に、外枠としての仮想端末自体を制御するためのコマンド文字が存在します。例えば、新しくシェル画面を追加したり、並行処理している複数のシェル画面を切り替えたりします。その制御用の文字を、エスケープ文字と呼びますが、これを各サーバーで色々だと誤操作等の支障が出るので変更して統一しておきます。

エスケープ文字の変更は、byobu が起動している画面で F9 キーを押下するとメニューのダイアログが起動します。 screen との相性が悪いらしく、表示が崩れますが変更は出来るようです。変更した結果のファイルを確認すると文字列が追加されていました。

$ vi .byobu/keybindings

source $BYOBU_PREFIX/share/byobu/keybindings/common
bindkey "^B"
escape "^Bb"
register x "^B"
~

ただし、このままでは sshでリモートログインしても自動的に byobu は起動しないし、 byobu を終了しても sshでログインした状態のままになります。

$ byobu-enable

The Byobu window manager will be launched automatically at each text login.

To disable this behavior later, just run:
byobu-disable

これでクライアントからの ssh リモート接続でセッションが確立すると、自動的に byobu が起動して、過去に操作していたなら以前の状態の継続になります。リモートでの操作を終えるために F6 キーによる終了で、 ssh によるリモート接続も自動的に切断します。

byobu の操作は、新規に仮想端末を追加で開くには F2 キー、別画面に移動するには、左回り右回りで F3 / F4 キーで行います。

これで仮想端末 byobu の設定は完了です。