en_k-makino
2025年7月24日 17時17分
==========
製品型番：AGX4520-C03D0
Debian/ABOSバージョン：3.21.3-at.3
カーネルバージョン：5.10.235-0-at
3G/LTE モジュール情報 (Debianのみ)：
その他：
==========
以下を参考に、簡易Webサーバーでソフトウェアをリモートアップデートしています。
https://armadillo.atmark-techno.com/blog/15349/12602
リモートアップデート自体は問題なく行えていますが、
アップデートを行う時刻についてご教授いただきたく存じます。
上記サイトの「３．swupdate-urlの設定」にて以下のとおり変更しています。
[armadillo]# echo 'schedule="17:00:00' > /etc/conf.d/swupdate-url
[armadillo]# echo 'rdelay="10"' >> /etc/conf.d/swupdate-url
この設定だと、17:00:00～17:00:10の時刻にアップデートが行われると認識していますが、
実際にアップデートが行われたのは、16:57:57でした。
何パターンかの設定を試みましたが、設定時刻とはズレた時刻にアップデートが行われました。
何か設定が抜けている、もしくは間違えているところがあるのでしょうか？
または、認識自体が違うのでしょうか？
ご教授のほど、よろしくお願いいたします。
コメント
en_k-makino
マルティネさん
お世話になります。
en_k-makinoです。
> en_k-makinoさん
>
> お世話になっています、
> マルティネです。
>
> > 上記サイトの「３．swupdate-urlの設定」にて以下のとおり変更しています。
> > [armadillo]# echo 'schedule="17:00:00' > /etc/conf.d/swupdate-url
>
> 頂いた質問と関係ないですが、確認させてください。
>
> 「"」 が一つ抜けてますが、小アマンドをコピーしていただいた際の問題でしょうか。
申し訳ございません、ご指摘のとおりコピーした際のミスです。実際は正しく入力しています。
> また、時間だけを「17:00:00」のように記載すると、17時移行に次の時刻を計算すると過去の時刻として出てしまって、swupdate-url サービスが停止されます。毎日 17時にアップデートを実行したい場合は「17:00:00 tomorrow」（か「17 tomorrow」でも。date -d @$(schedule_ts '17 tomorrow') で確認できます）
>
> > この設定だと、17:00:00～17:00:10の時刻にアップデートが行われると認識していますが、
> > 実際にアップデートが行われたのは、16:57:57でした。
> > 何パターンかの設定を試みましたが、設定時刻とはズレた時刻にアップデートが行われました。
> >
> > 何か設定が抜けている、もしくは間違えているところがあるのでしょうか？
>
> なんでしょうね。
> こちらの自動アップデートスクリプトの目的としては正確な時刻でアップデートを実施するのではなく、サーバーの負担を減らすために全ての Armadillo が同時にアップデートを行わないようにできてますので、実装はかなりシンプルです：
> 次のアップデート時刻を計算して、それまでの秒数を計算して、sleep コマンドでそれまで待ってからアップデートを実行するだけです。
> （再起動が挟む場合は前に計算したアップデート時刻から再び sleep が必要な秒数を計算して待つか、過去の場合は直ちにアップデートを実施します）
>
> アップデート時刻を計算した後にシステム時刻を修正しても sleep 時間の修正はないので、そういうところにズレが発生する可能性はありますが、それでも２分のズレは大きいような気がします…
> 確認のため手元の Armadillo IoT G4 で 15時間を sleep させて明日の朝にどれぐらいズレたかを確認しますので、少し時間をください。
よろしくお願いいたします。
結果のご連絡お待ちいたしております。
> また、次のアップデート予定は「date -d @$(cat /var/log/swupdate/swupdate-url.state)」で確認できますが、そちらは 17:00:00~17:00:10 の間で間違いないでしょうか？
合っています。17:00:03でした。
> > または、認識自体が違うのでしょうか？
>
> rdelay と schedule パラメターの認識は合ってます。
>
> よろしくお願いします。
承知いたしました。
at_dominique.m…
en_k-makinoさん
マルティネです。
> > アップデート時刻を計算した後にシステム時刻を修正しても sleep 時間の修正はないので、そういうところにズレが発生する可能性はありますが、それでも２分のズレは大きいような気がします…
> > 確認のため手元の Armadillo IoT G4 で 15時間を sleep させて明日の朝にどれぐらいズレたかを確認しますので、少し時間をください。
> よろしくお願いいたします。
> 結果のご連絡お待ちいたしております。
結果としてはズレがありませんでした (sleep 1 でも 10ms ズレてますので、長いスパンと関係ありません）
# date +%N を利用するために coreutils を一時的にインストールしました armadillo:~# apk add coreutils armadillo:~# date +%T.%N; sleep $((3600*15)); date +%T.%N 18:12:49.320633089 09:12:49.332001998
（今朝気づきましたが、coreutils のパッケージ追加で sleep も busybox sleep にするべきでしたが、実装としてはどちらも nanosleep() を使ってるだけなので確認としては問題ないと考えています。
nanosleep() の実装としては CLOCK_MONOTONIC を使っているため、ntp の同期などで時刻がずれても待つ時間に影響はないので、ntp取得前に計算した場合などにズレがでます。）
>> また、次のアップデート予定は「date -d @$(cat /var/log/swupdate/swupdate-url.state)」で確認できますが、そちらは 17:00:00~17:00:10 の間で間違いないでしょうか？
> 合っています。17:00:03でした。
了解しました。
続いての確認ですみませんが、/var/log/messages にこう言うメッセージが残るはずです。
これで原因がわかると思いますので、「grep swupdate /var/log/messages」の出力を提供していただけますでしょうか。
armadillo:~# grep swupdate /var/log/messages Jul 24 18:03:52 armadillo user.notice swupdate-url: Target date in the past Thu Jan 1 09:00:00 JST 1970: running now Jul 24 18:03:52 armadillo user.notice swupdate: Trying to update https://download.atmark-techno.com/armadillo-iot-g4/image/baseos-x2-latest.swu ... Jul 24 18:03:53 armadillo user.notice swupdate-url: Next run on Fri Jul 25 17:00:08 JST 2025, sleeping 82575s
また、よろしければ、何か実行時刻にこだわる理由があれば教えていただけますでしょうか？
最初に書いた通り、swupdate-url の設計としては正確に実行するようには考えてませんので、重要度によっては改善できると思います。
よろしくお願いします。
en_k-makino
> en_k-makinoさん
>
> マルティネです。
>
> > > アップデート時刻を計算した後にシステム時刻を修正しても sleep 時間の修正はないので、そういうところにズレが発生する可能性はありますが、それでも２分のズレは大きいような気がします…
> > > 確認のため手元の Armadillo IoT G4 で 15時間を sleep させて明日の朝にどれぐらいズレたかを確認しますので、少し時間をください。
> > よろしくお願いいたします。
> > 結果のご連絡お待ちいたしております。
>
> 結果としてはズレがありませんでした (sleep 1 でも 10ms ズレてますので、長いスパンと関係ありません）
>
> # date +%N を利用するために coreutils を一時的にインストールしました > armadillo:~# apk add coreutils > armadillo:~# date +%T.%N; sleep $((3600*15)); date +%T.%N > 18:12:49.320633089 > 09:12:49.332001998 >
> （今朝気づきましたが、coreutils のパッケージ追加で sleep も busybox sleep にするべきでしたが、実装としてはどちらも nanosleep() を使ってるだけなので確認としては問題ないと考えています。
> nanosleep() の実装としては CLOCK_MONOTONIC を使っているため、ntp の同期などで時刻がずれても待つ時間に影響はないので、ntp取得前に計算した場合などにズレがでます。）
>
> >> また、次のアップデート予定は「date -d @$(cat /var/log/swupdate/swupdate-url.state)」で確認できますが、そちらは 17:00:00~17:00:10 の間で間違いないでしょうか？
> > 合っています。17:00:03でした。
>
> 了解しました。
> 続いての確認ですみませんが、/var/log/messages にこう言うメッセージが残るはずです。
> これで原因がわかると思いますので、「grep swupdate /var/log/messages」の出力を提供していただけますでしょうか。
>
>
> armadillo:~# grep swupdate /var/log/messages > Jul 24 18:03:52 armadillo user.notice swupdate-url: Target date in the past Thu Jan 1 09:00:00 JST 1970: running now > Jul 24 18:03:52 armadillo user.notice swupdate: Trying to update https://download.atmark-techno.com/armadillo-iot-g4/image/baseos-x2-latest.swu > ... > Jul 24 18:03:53 armadillo user.notice swupdate-url: Next run on Fri Jul 25 17:00:08 JST 2025, sleeping 82575s >
>
>
> また、よろしければ、何か実行時刻にこだわる理由があれば教えていただけますでしょうか？
> 最初に書いた通り、swupdate-url の設計としては正確に実行するようには考えてませんので、重要度によっては改善できると思います。
>
> よろしくお願いします。
ご確認ありがとうございました。
時刻にズレが生じないとのこと、承知いたしました。
ご依頼のログを添付しますので、ご確認のほどよろしくお願いいたします。
実行時刻にこだわる理由につきまして、
大変申し訳ございませんが、現状具体的な何かがあるというわけではございません。
今後活用できる可能性が非常に高いと感じたため、是非使い方を知っておきたいと考えた次第です。
| ファイル | ファイルの説明 |
|---|---|
| swupdate_log.txt | 「grep swupdate /var/log/messages」の内容 |
at_dominique.m…
マルティネです。
> 時刻にズレが生じないとのこと、承知いたしました。
> ご依頼のログを添付しますので、ご確認のほどよろしくお願いいたします。
Jul 24 16:57:09 armadillo user.notice swupdate-url: Target date in the past Thu Jul 24 16:50:06 JST 2025: running now Jul 24 16:57:57 armadillo user.info swupdate: SUCCESS SWUPDATE successful ! Jul 24 16:58:20 armadillo user.notice swupdate-url: Target date in the past Thu Jul 24 16:50:06 JST 2025: running now Jul 24 16:58:21 armadillo user.notice swupdate-url: Next run on Thu Jul 24 17:00:01 JST 2025, sleeping 100s Jul 24 17:00:02 armadillo user.notice swupdate-url: auto-update error: schedule 17:00:00 is in the past? Would be T)
上記のログでは、おそらく 17:00:00 を試す前に 16:50:00 で試していたと思いますが、サービスをリスタートする際に前の目標が過ぎて直地に実行されただけのようですね。
（16:57:57 はアップデート完了時間でした）
schedule の設定を変更しても前のアップデート予定がすでにある場合はそちらが優先されてますので、これは正常です。
間欠動作などで再起動する場合は毎回スケジュールを計算し直すと永遠にアップデートしない恐れがありますので、アップデート予定を計算する際にeMMC にその時刻を保存して、サービススタート時は eMMC にある時刻を優先します。
また、複数の url を対応するためにアップデートが成功してもすぐに次の時刻を更新してなくて、アップデート成功の再起動の後にもう一度アップデートを試してから次の時刻を計算しています。
（こちらの動作は、再起動せずに複数の swu をインストールできるように改善できたら変わる可能性があります）
また、最後のエラーは最初の返事に書いたように、「17:00:00」 ではなく「17:00:00 tomorrow」として設定する必要があるからです。
こちらのエラーは起きやすいので、schedule 時刻が過去の場合に +1日も試してみてからエラーさせるように変更してみます。
> 大変申し訳ございませんが、現状具体的な何かがあるというわけではございません。
> 今後活用できる可能性が非常に高いと感じたため、是非使い方を知っておきたいと考えた次第です。
説明ありがとうございます、了解しました。
ログで原因がわかりましたので、とりあえず現状のままで問題ないと思いますが、
何か不都合があればまた聞いてください。
en_k-makino
> マルティネです。
>
> > 時刻にズレが生じないとのこと、承知いたしました。
> > ご依頼のログを添付しますので、ご確認のほどよろしくお願いいたします。
>
>
> Jul 24 16:57:09 armadillo user.notice swupdate-url: Target date in the past Thu Jul 24 16:50:06 JST 2025: running now > Jul 24 16:57:57 armadillo user.info swupdate: SUCCESS SWUPDATE successful ! > Jul 24 16:58:20 armadillo user.notice swupdate-url: Target date in the past Thu Jul 24 16:50:06 JST 2025: running now > Jul 24 16:58:21 armadillo user.notice swupdate-url: Next run on Thu Jul 24 17:00:01 JST 2025, sleeping 100s > Jul 24 17:00:02 armadillo user.notice swupdate-url: auto-update error: schedule 17:00:00 is in the past? Would be T) >
>
> 上記のログでは、おそらく 17:00:00 を試す前に 16:50:00 で試していたと思いますが、サービスをリスタートする際に前の目標が過ぎて直地に実行されただけのようですね。
> （16:57:57 はアップデート完了時間でした）
>
> schedule の設定を変更しても前のアップデート予定がすでにある場合はそちらが優先されてますので、これは正常です。
> 間欠動作などで再起動する場合は毎回スケジュールを計算し直すと永遠にアップデートしない恐れがありますので、アップデート予定を計算する際にeMMC にその時刻を保存して、サービススタート時は eMMC にある時刻を優先します。
>
> また、複数の url を対応するためにアップデートが成功してもすぐに次の時刻を更新してなくて、アップデート成功の再起動の後にもう一度アップデートを試してから次の時刻を計算しています。
> （こちらの動作は、再起動せずに複数の swu をインストールできるように改善できたら変わる可能性があります）
>
> また、最後のエラーは最初の返事に書いたように、「17:00:00」 ではなく「17:00:00 tomorrow」として設定する必要があるからです。
> こちらのエラーは起きやすいので、schedule 時刻が過去の場合に +1日も試してみてからエラーさせるように変更してみます。
>
> > 大変申し訳ございませんが、現状具体的な何かがあるというわけではございません。
> > 今後活用できる可能性が非常に高いと感じたため、是非使い方を知っておきたいと考えた次第です。
>
> 説明ありがとうございます、了解しました。
> ログで原因がわかりましたので、とりあえず現状のままで問題ないと思いますが、
> 何か不都合があればまた聞いてください。
問題ない旨、承知いたしました。
ご対応ありがとうございました。
at_dominique.m…
2025年7月24日 18時19分
en_k-makinoさん
お世話になっています、
マルティネです。
> 上記サイトの「３．swupdate-urlの設定」にて以下のとおり変更しています。
> [armadillo]# echo 'schedule="17:00:00' > /etc/conf.d/swupdate-url
頂いた質問と関係ないですが、確認させてください。
「
"」 が一つ抜けてますが、小アマンドをコピーしていただいた際の問題でしょうか。また、時間だけを「17:00:00」のように記載すると、17時移行に次の時刻を計算すると過去の時刻として出てしまって、swupdate-url サービスが停止されます。毎日 17時にアップデートを実行したい場合は「17:00:00 tomorrow」（か「17 tomorrow」でも。
date -d @$(schedule_ts '17 tomorrow')で確認できます）> この設定だと、17:00:00～17:00:10の時刻にアップデートが行われると認識していますが、
> 実際にアップデートが行われたのは、16:57:57でした。
> 何パターンかの設定を試みましたが、設定時刻とはズレた時刻にアップデートが行われました。
>
> 何か設定が抜けている、もしくは間違えているところがあるのでしょうか？
なんでしょうね。
こちらの自動アップデートスクリプトの目的としては正確な時刻でアップデートを実施するのではなく、サーバーの負担を減らすために全ての Armadillo が同時にアップデートを行わないようにできてますので、実装はかなりシンプルです：
次のアップデート時刻を計算して、それまでの秒数を計算して、sleep コマンドでそれまで待ってからアップデートを実行するだけです。
（再起動が挟む場合は前に計算したアップデート時刻から再び sleep が必要な秒数を計算して待つか、過去の場合は直ちにアップデートを実施します）
アップデート時刻を計算した後にシステム時刻を修正しても sleep 時間の修正はないので、そういうところにズレが発生する可能性はありますが、それでも２分のズレは大きいような気がします…
確認のため手元の Armadillo IoT G4 で 15時間を sleep させて明日の朝にどれぐらいズレたかを確認しますので、少し時間をください。
また、次のアップデート予定は「
date -d @$(cat /var/log/swupdate/swupdate-url.state)」で確認できますが、そちらは 17:00:00~17:00:10 の間で間違いないでしょうか？> または、認識自体が違うのでしょうか？
rdelay と schedule パラメターの認識は合ってます。
よろしくお願いします。