follow me

[emo] 時刻同期について書くよ

2020年も終わりそうです、ぼっちで Advent Calendar を続けています。
1年も関わってしまっていたユカイ工学株式会社の「BOCCO emo」について赤裸々に書き綴ろう。


今日は、時刻同期 について。
RTCを積んでいないデバイスって多いですよね。
RTCを使うとなると、どうしても電池なりを入れないといけなくなるので、使いたくないですね。
ネットワーク使用前提の製品だと、NTPを利用するパターンが多いですよね。
BOCCO emoでも、NTPは利用しています。でも、それだけじゃないんです。というお話です。


まずは時刻同期に、NTPサーバを利用するというのは、製品としては良くある話ですね。
勿論、NTPサーバを自社で運用してという処までやる場合もあるかと思いますが、生産の見込台数から外部のNTPサーバを利用するのも良いでしょう。
外部のNTPサーバを利用する場合、1つのサービスに依存してしまわない様にしておく等考慮しておくべきかと思われます。
特に、通信をSSLのみに頼っている場合、時刻同期ができない為に、倉庫に眠っていた製品がユーザに届いたが、実は通信できなくなっていたなんて間抜けな笑い話は犬も喰いません。

また、前日少し記載しましたが、ネットワーク疎通タイミングと、時刻同期までの、タイムラグを小さくするというのも、製品の体感に大きく関わってきます。
そういった調整が、実際に製品が機能するまでのユーザの待ち時間を減らす結果となります。
ユーザが時刻同期待ちとかイケテナイですからね。

NTPを利用する際、時刻同期がされた状態なのか知りたい場合もあると思います。
勿論、ntpのコマンドをexecするという方法もあると思います。
でも、極力execとか使いたくないと思うことがあると思います。
OpenWrtのsysnptdだと、Hotplugの仕組みのおかげで、同期済みなのか判断できる様になっていたりします。これを利用するのもいいでしょう。
内容は、/etc/hotplug.d/ntp/25-dnsmasqsec を見ると解るかと思います。/var/state/dnsmasqsec にファイルが生成されていますね。
#!/bin/sh

. /lib/functions/procd.sh

TIMEVALIDFILE="/var/state/dnsmasqsec"

[ "$ACTION" = stratum ] || exit 0

[ -f "$TIMEVALIDFILE" ] || {
        echo "ntpd says time is valid" >$TIMEVALIDFILE
        /etc/init.d/dnsmasq enabled && {
                procd_send_signal dnsmasq '*' INT
        }
}


RTCを載せるという裏技
BOCCO emoには、拡張ボードを刺す為のコネクタが付いています。
このコネクタ仕様が、一般公開されるのかは未だ不明なままですが、ユカイ工学株式会社の記事を眺めていると、公開APIも充実させる方向の様なので、今後に期待といった処でしょうか。
ここにRTCモジュールを搭載させて、ネットワークに繋がらないタイミングでも、正しい時刻を使おうというのも1つの手として存在しています。
ハードも作ってるユカイ工学株式会社では、そういう実装も可能です。


時間が戻って欲しくない
ここが今回の本題なのですが、RTCを持っていない BOCCO emo では、電源が切れれば時刻同期するまで正確な時間が取得できません。
時間が正確かは妥協するとしても、
電源OFF状態からの電源ON時に時間を巻き戻したくない、というのは、組込Linux等を利用した製品では良くある事かと思います。
特にDB系を使い出すと時間の巻き戻りは面倒です。また、ファイルのタイムスタンプを何かに利用した場合、更に面倒です。
だからRTCをつけるという選択があるのですが、やはり電池を入れるというのは避けたいというのもあります。
では、完全回避とまではいかないにしても、時間の巻き戻りの発生を小さくする事は可能なので、それを実装します。

BOCCO emoでは、1から実装するのも面倒なので、Raspberry Pi等で利用されている、fake-hwclock を利用しています。
https://git.einval.com/git/fake-hwclock.git
これで、再起動での時間の巻き戻りを抑えています。

BOCCO emo には、個人的に OpenWrt に組み込める様にしたものを流用しています。
https://github.com/srchack/custom-packages/tree/master/fake-hwclock
少しだけ、修正をいれています。
時刻設定復帰時に、NTPで同期できているなら、上書きをしてしまわない様にしています。(上書きで巻き戻るケースが考えられます。
NTPで取得できる時刻を信じきった実装ですが、まぁNTPが信用できなくなると、そもそも信用できない部分は多いですし。
fake-hwclock 自体は、スクリプトで実装されていて行数も短い(100行も無い)ので、さくさくと読めてしまうと思いますので、製品等に組み込むのは容易かと思います。

ちなみに、fake-hwclock が入っていなくても、ntpclient 等を利用すれば、デフォルト10m間隔で時刻が保存され、再起動等した際には、それ以上戻らない様な動きが入っている様にみえます。
ntpclient を併用する場合、fake-hwclock が干渉してしまう可能性も注意しないといけません。


ファーム初期状態の始まり時刻
OpenWrt 19..07.4 時点では、$SOURCE_DATE_EPOCH が効いていて、利用した OpenWrt の git の最終コミット時間になります。
なので、ファーム次第で初回起動時の時刻は異なります。
ファームのリビジョンを上げていくと勿論、変動していくので、この日時だから初回起動だ(時刻同期できていない)という判断は、危険です。
正しい時刻の状態なのかの判断する材料は存在するので、その判断材料を利用しましょう。


NTPで設定と一言で終わりになる事の多い時刻同期ですが、考え出すと面倒ですね。
みなさんは、製品での時刻同期はどうされていますか?
最近では、セキュリティも気にして、Network Time Security(NTS) をという事もあるのでしょうか?
僕はまだまだ勉強不足ですね。勉強し直します。


今日は今日です、昨日には戻らないのです。Advent Calendar 2020、22日目でした。
次は 悩み中です。

ユカイ工学株式会社の「BOCCO emo」、製品としてどうかはともかくとして、Linuxの箱としてはとりあえず遊べるオモチャにはなってる気がします。
最近、オモチャ触る時間ないですがね。そして時は動き出す。
23日目の記事も早速書かないとですね。がんばります。
でわ、また明日。
[emo] 時刻同期について書くよ | 0 件のコメント | アカウント登録
サイト管理者はコメントに関する責任を負いません。