私のコンピュータで実行していますが、正常に動作してntpdいるかどうかはわかりません。ntpdタイムサーバーへの接続が成功したかどうか、カーネル時刻が同期していることを確認するためにクエリを実行するにはどうすればよいですか？
ベストアンサー1
ntpd動作しているかどうかを確認する方法はいくつかあります。
使用するか、
ntpq -pDNSntpq -pn検索をスキップして時間を節約してください。NTPの実際の外観は次のとおりです。
host-a ~ # ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== 0.debian.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.000 1.debian.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.000 2.debian.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.000 3.debian.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.000 +mail.masters-of 144.76.76.107 3 u 975 1024 377 13.731 -0.737 2.552 +ntp2.hetzner.de 124.216.164.14 2 u 232 1024 377 15.914 -0.650 0.854 +rondra.lf-net.o 237.17.204.95 2 u 1020 1024 377 13.751 -0.557 4.292 -funky.f5s.de 131.188.3.222 2 u 480 1024 377 15.730 2.082 4.377 +stratum2-3.NTP. 129.70.137.82 2 u 742 1024 377 19.785 -0.366 7.498 *mail.klausen.dk 193.79.237.14 2 u 173 1024 377 14.383 -0.513 2.066*同期したいソースを表す接続された物理ピアが一覧表示されます。出力の詳細については、以下で確認できます。NTP文書。ないときは次のようになります。
host-b ~ # ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== 0.debian.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.000 1.debian.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.000 2.debian.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.000 3.debian.pool.n .POOL. 16 p - 64 0 0.000 0.000 0.000記載されている実際のピアがないことに注意してください。これは通常、
ntpdファイアウォールが接続をブロックしているため、ピアに接続できないことを示します。ntpq -p出力を解析する必要があるため、スクリプトチェックには適していません。速度（呼び出しあたり30ミリ秒）は問題ありませんが、より速い方法については後で説明します。お使いの方は
systemdお使いくださいtimedatectl status。NTPの実際の様子は次のとおりです（参考
System clock synchronized: yes）。host-a ~ # timedatectl status Local time: Do 2021-04-22 13:29:20 CEST Universal time: Do 2021-04-22 11:29:20 UTC RTC time: Do 2021-04-22 11:29:21 Time zone: Europe/Berlin (CEST, +0200) System clock synchronized: yes NTP service: inactive RTC in local TZ: noない時の様子は次のとおりです（参考
System clock synchronized: no）。host-b ~ # timedatectl status Local time: Do 2021-04-22 13:29:53 CEST Universal time: Do 2021-04-22 11:29:53 UTC RTC time: Do 2021-04-22 11:29:42 Time zone: Europe/Berlin (CEST, +0200) System clock synchronized: no NTP service: inactive RTC in local TZ: no（独自のNTPクライアントを
NTP service参照してください。インストール時に実行しないでください。これは予想される結果です。）systemd-timesyncdsystemdntpdnotimedatectl statussystemd-timedated要求時にのみ開始されたクエリの場合、最初の呼び出しで約100ミリ秒の小さなパフォーマンスが低下します。追加の呼び出しには約12ミリ秒かかります。systemd-timedatedadjtimex(2)システムコールはカーネルを照会するために順番に使用されます。adjtimex(2)このビットがセットされた状態でステータスが返されると、クロックはSTA_UNSYNC同期されません。timedatectlこれは実際に通信するのではなく、同期状態が変わるたびにNTPサービスによって更新されるntpdカーネルに格納されているビットを照会することを意味します。ntpdtimedatectl status関連プロパティを直接クエリできるため、スクリプトに適しています。host-a ~ # timedatectl show -p NTPSynchronized --value yes host-b ~ # timedatectl show -p NTPSynchronized --value no直接使用
adjtimex(2):これはユーザーにとって最もわかりにくい方法ですが、スクリプトの場合は最も高速です。
busyboxDebian バスターは、システムコールの簡単なラッパーとしてadjtimex機能する小さなプログラムを提供します。adjtimex(2)NTPの実際の外観は次のとおりです。
host-a ~ # busybox adjtimex mode: 0 -o offset: -570098 us -f freq.adjust: 857283 (65536 = 1ppm) maxerror: 478704 esterror: 302 status: 8193 (PLL) -p timeconstant: 10 precision: 1 us tolerance: 32768000 -t tick: 10000 us time.tv_sec: 1619092119 time.tv_usec: 60467600 return value: 0 (clock synchronized)存在しない時の様子は次のとおりです（行
UNSYNCの合計を参照status）。host-b ~ # busybox adjtimex mode: 0 -o offset: 0 us -f freq.adjust: 2126708 (65536 = 1ppm) maxerror: 16000000 esterror: 16000000 status: 16449 (PLL | UNSYNC) -p timeconstant: 7 precision: 1 us tolerance: 32768000 -t tick: 10000 us time.tv_sec: 1619091984 time.tv_usec: 307119 return value: 5 (clock not synchronized)残念ながら、
busybox adjtimex特定のフィールドだけを印刷する方法はないようです。戻り値は実際には返されず、印刷されるだけです。これは、スクリプトのために出力（たとえば）を解析する必要があることを意味しますbusybox adjtimex | grep -q UNSYNC。一方、非常に高速（わずか0.5ミリ秒）でこれを補完します！