コグノスケ

NTPの時刻同期状況

目次: 自宅サーバー

NTPの動作状況を見るときに使うコマンドのメモです。よく使うのはntpq -pで、上流のNTPサーバーの一覧と同期状況が表示されます。

$ ntpq -p

     remote           refid      st t when poll reach   delay   offset   jitter
===============================================================================
+time.cloudflare 10.150.8.4       3 8   49   64   37   3.8613   0.5451   0.0948
*ntp-a2.nict.go. .NICT.           1 u   38   64   37   4.7874  -0.0892   0.1767
+ntp2.jst.mfeed. 133.243.236.17   2 u   43   64   37   4.1815  -1.1453   0.1508

NTPがシステム時刻と同期しているかを見るにはtimedatectlを使うと便利です。このツールはsystemdの一部のようです。

$ timedatectl status
               Local time: 土 2026-08-08 01:57:36 JST
           Universal time: 金 2026-08-07 16:57:36 UTC
                 RTC time: 金 2026-08-07 16:57:36
                Time zone: Asia/Tokyo (JST, +0900)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

何をもってSystem clock synchronizedだと判断するか良くわからんので、systemdのコードを見てみると、

// systemd-255.5/src/timedate/timedated.c

static bool ntp_synced(void) {
        struct timex txc = {};

        if (adjtimex(&txc) < 0)
                return false;

        /* Consider the system clock synchronized if the reported maximum error is smaller than the maximum
         * value (16 seconds). Ignore the STA_UNSYNC flag as it may have been set to prevent the kernel from
         * touching the RTC. */
        return txc.maxerror < 16000000;
}

static BUS_DEFINE_PROPERTY_GET_GLOBAL(property_get_time, "t", now(CLOCK_REALTIME));
static BUS_DEFINE_PROPERTY_GET_GLOBAL(property_get_ntp_sync, "b", ntp_synced());    //★たぶんこれ★


// systemd-255.5/src/timedate/timedated.c

static int print_status_info(const StatusInfo *i) {

...

        r = table_add_many(table,
                           TABLE_FIELD, "System clock synchronized",
                           TABLE_BOOLEAN, i->ntp_synced,    //★これ★
                           TABLE_FIELD, "NTP service",
                           TABLE_STRING, i->ntp_capable ? (i->ntp_active ? "active" : "inactive") : "n/a",
                           TABLE_FIELD, "RTC in local TZ",
                           TABLE_BOOLEAN, i->rtc_local);
        if (r < 0)
                return table_log_add_error(r);

システムコールadjtimexが成功すること、maxerrorが16000000us = 16sより小さいこと、双方を満たすとSystem clock synchronizedと判断します。adjtimexにはクロックが非同期状態であることを示すSTA_UNSYNCフラグがあるものの、無視しています。

コメント曰くあえて無視していて、カーネルがRTCにアクセスするのを防ぐためなのだそうですが、説明がイマイチ良くわからんね……。

NTPの時刻同期状況をグラフ化

NTPの時刻同期をグラフ化する方法はいくつかあるようですが、Debian（通常はntpd = ntpsec）を使っているのであればntpsec-ntpvizが便利です。下記のように使います。

#### /etc/ntpsec/ntp.confに下記の設定を加える、デフォルトで有効かもしれない

statsdir /var/log/ntpsec/
statistics loopstats peerstats clockstats

設定変更した後はsudo systemctl restart ntpsecをするのをお忘れなく。

$ sudo apt-get install ntpsec-ntpviz

$ sudo mkdir /var/www/html/ntpviz
$ sudo ntpviz -d /var/log/ntpsec/ -o /var/www/html/ntpviz

ブラウザでntpvizが生成したindex.htmlを表示すると各種グラフが表示されるはずです。HTTPサーバを動作させていない場合は、ファイルをコピーしてきてブラウザで見ても良いです。

ADS-Bを送る時刻に注意

目次: 自宅サーバー

以前、Flightradar24のcontributorになる方法（2026年7月13日の日記参照）を紹介しました。ADS-Bの受信情報を送るシステムを構築してしばらく運用していたところ、いつのまにかcontributorからfreeに戻っていました。ええ？なんで？？

原因がわからんので調べます。まず入口の受信機側を見ましょう。ADS-B受信・デコードです。readsbは元気に動作していて、viewadsbで見ても大量に飛行機の情報が表示され続けるので、ADS-Bの電波受信とデコードに問題はなさそうです。

出口のWebサービス側も見ましょう。Flightradar24のstatusを見ると、STATUS Onlineなので通信はできていそうです。一方でAIRCRAFT SEEN 0になっているため、ADS-Bデータは送っているけど無効もしくは捨てているのかもしれません。Webサービス側より受信機側が怪しそうです。

時刻は大事

で、ADS-Bの受信機側（OKdo/radxa ROCK 5B、Linuxが動くARM SBC）を見ていたら、時刻が分単位でズレていることに気づきました。もしかして時間がズレすぎで、異常データ判定されてるのかな？裏付けを取るためにntpdateで時刻ずれを直してからfr24feedサービスを再起動したところ、AIRCRAFT SEENのカウントが増えるようになりました。やったぜ。

ROCK5Bは放置しているとどんどん時間がズレていってしまうこともわかったので、また同じ問題にハマらないように、ntpsecの設定にいくつかNTPサーバーを足しておきました。これで何とかなるでしょう。