ntpq -pの結果が全てstratum 16になっている

一般公開されている上位サーバーを適当に10個登録して運用していたのですが、どうも時刻が合っていないと思い確認したら、次のように10個ともstratum 16でした。
# ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
gps2.kek.jp .INIT. 16 u - 1024 0 0.000 0.000 0.000
133.40.41.136 .INIT. 16 u - 1024 0 0.000 0.000 0.000
2404:d540:1:41: .INIT. 16 u - 1024 0 0.000 0.000 0.000
ntp-a3.nict.go. .INIT. 16 u - 1024 0 0.000 0.000 0.000
ntp1.jst.mfeed. .INIT. 16 u - 1024 0 0.000 0.000 0.000
ntp1.odn.ne.jp .INIT. 16 u - 1024 0 0.000 0.000 0.000
ntp2.jst.mfeed. .INIT. 16 u - 1024 0 0.000 0.000 0.000
ntp3.jst.mfeed. .INIT. 16 u - 1024 0 0.000 0.000 0.000
104.20.50.205 .INIT. 16 u - 1024 0 0.000 0.000 0.000
131.107.13.100 .INIT. 16 u - 1024 0 0.000 0.000 0.000
ntpqによると、これら10個のサーバーはどれも信用できないと言っていますが、一般公開されているサーバーが10個とも信用できないというのは考えにくいため、ntpqの報告がおかしいのでしょうか。
この後のトラブルシューティングとして、やるべき事を教えてください
m(_ _)m

質問者からの補足コメント

• 

  また発生してしまいました。
  時刻同期が失敗したため、ntpq -pを実行したら、また結果が全てstratum 16になっていました。
  今回はログを取っていたので確認すると、
  ・・・
  29 Jul 14:17:30 ntpd[5974]: synchronized to 210.173.160.57, stratum 2
  ・・・
  29 Jul 14:34:06 ntpd[2169]: getaddrinfo: "ntp2.jst.mfeed.ad.jp" invalid host address, ignored
  のように、それまでずっと定期的にsynchronizedを出力していたのに、29日にinvalid host addressのエラーを吐いて、それ以降ログ出力が途絶えていました。
  例によって再起動すると、問題なく動き始めましたが、根本的な解決ではないので、原因を突き止めたいです。

    補足日時：2022/07/31 15:38

No.11 ベストアンサー 回答者： trka 回答日時： 2022/08/04 10:46

あまりご参考になるような結果になりませんでしたが、私の自宅環境におけるntpqの結果です。

私の自宅環境もご質問者様とほぼ同様...

●時々同期サーバは変更される。
●私の環境もpoll時間は1024secより上の値とはなりませんでした。
●reach 377は直近の8回の通信全てで成功ですので 1024(sec) x 8(回)=8192(sec)/3600(sec/h)=2.275(h) の間は、問題なく通信できていることを示します。

となりました。ご質問者様の問題は、現象再発までに時間が掛かり、原因特定することが難しいと思われるのですが、次の様なことが考えられるのではないでしょうか。

1)DNSサーバをご自身で立てていらっしゃるとの事で、こちらを攻めてみる。
サーバとなるbindを落とすと、ntpqで同様なエラーが発生するか。あるいはbindが利用するメモリ、プロセス優先度などを低下させて影響は出ないか。

2)ntp.confでntpサーバをipアドレスで指定すれば、同様のエラー発生の頻度は少なくなるのではないかと予測します。つまり、単なる様子見ですが。

$ date; ntpq -p

2022年 8月 2日 火曜日 02:50:46 JST
remote refid st t when poll reach delay offset jitter
==============================================================================
+ntp-a3.nict.go. .NICT. 1 u 366 1024 377 181.702 -10.801 25.268
+ntp-a2.nict.go. .NICT. 1 u 495 1024 377 153.070 -11.180 24.642
-ns2.tdc.akl.tel [phone] 2 u 133 1024 377 254.730 -62.828 59.625
+ntp-b3.nict.go. .NICT. 1 u 964 1024 377 149.895 -14.165 30.632
*ntp-b2.nict.go. .NICT. 1 u 290 1024 377 159.573 -13.713 27.624
-ntp-k1.nict.jp .NICT. 1 u 288 1024 377 63.563 -65.543 74.232

2022年 8月 2日 火曜日 16:25:51 JST
remote refid st t when poll reach delay offset jitter
==============================================================================

+ntp-a3.nict.go. .NICT. 1 u 757 1024 377 41.595 -10.312 33.760
+ntp-a2.nict.go. .NICT. 1 u 20 1024 377 58.434 -3.581 38.165
+ns2.tdc.akl.tel [phone] 2 u 587 1024 377 251.316 -6.112 40.876
+ntp-b3.nict.go. .NICT. 1 u 493 1024 377 51.461 -4.811 44.930
*ntp-b2.nict.go. .NICT. 1 u 539 1024 377 50.224 -4.655 50.367

2022年 8月 3日 水曜日 14:28:58 JST
remote refid st t when poll reach delay offset jitter
==============================================================================

+ntp-a3.nict.go. .NICT. 1 u 796 1024 377 43.895 -1.512 77.003
+ntp-a2.nict.go. .NICT. 1 u 458 1024 377 54.680 +4.304 30.757
+ns2.tdc.akl.tel [phone] 2 u 618 1024 377 243.906 -3.647 79.137
+ntp-b3.nict.go. .NICT. 1 u 554 1024 377 57.948 -8.281 32.104
*ntp-b2.nict.go. .NICT. 1 u 681 1024 377 38.626 -3.227 52.743

022年 8月 4日 木曜日 07:11:02 JST
remote refid st t when poll reach delay offset jitter
==============================================================================

+ntp-a3.nict.go. .NICT. 1 u 691 1024 337 57.560 +6.227 41.330
+ntp-a2.nict.go. .NICT. 1 u 410 1024 377 40.620 -4.225 49.458
+ns2.tdc.akl.tel [phone] 2 u 640 1024 377 258.507 -0.608 36.708
*ntp-b3.nict.go. .NICT. 1 u 394 1024 377 57.306 +6.303 20.278
+ntp-b2.nict.go. .NICT. 1 u 586 1024 377 69.258 +11.830 24.617

この回答へのお礼

pollとreachの意味が分かりました。
namedを停止してテストしてみたのですが、どういうわけか、namedを止めても時刻同期は失敗しませんでした。ntpは、namedが使えない時、何か別の名前解決法を持っているのでしょうか。
ntpq -pの結果は次のように、普段名前が表示される所にIPアドレスが表示され、同期を続けます。
# ntpq -p
remote refid st t when poll reach delay offset jitter
===========================================
+ntp1.jst.mfeed. 133.243.236.17 2 u 825 1024 377 11.407 -2.297 1.853
*ntp2.jst.mfeed. 133.243.236.18 2 u 52 1024 377 11.180 -0.221 0.369
+ntp3.jst.mfeed. 133.243.236.19 2 u 892 1024 377 9.723 -1.956 0.966
# /etc/init.d/named stop
named を停止中: [ OK ]
# ntpq -p
remote refid st t when poll reach delay offset jitter
===========================================
+210.173.160.27 133.243.236.17 2 u 99 1024 377 12.515 -0.558 0.114
*210.173.160.57 133.243.236.18 2 u 343 1024 377 11.180 -0.221 0.369
+210.173.160.87 133.243.236.19 2 u 157 1024 377 11.299 -0.893 0.097

あと、ntpq -pでstratum 16となっているサーバーはntp.confから消す事にしました。
そうしたら、ntpq -pの反応が、すごく早くなりました。
今まで5秒ぐらいかかっていたのが、一瞬で反応するようになりました。

お礼日時：2022/08/04 14:17

No.13 回答者： trka 回答日時： 2022/08/04 18:31

うーん。

他に誰か経験者無いでしょうかね。

この回答へのお礼

原因が分からず悔しいです。
しかし最後の手段として、下策ですが定期的にntpdを再起動するようにすれば大きな問題は発生しませんので、最悪そうします。

恐らくntpd、というかLinuxディストリ自体が古すぎるというのも原因なのでしょうね。

お礼日時：2022/08/04 18:51

No.12 回答者： trka 回答日時： 2022/08/04 15:16

IPアドレスの表示に変わるということは、ntpがキャッシュを持っていて、それを利用していると考えられないでしょうか。

DNSサーバにアクセスできない状態なら、例のログファイルに何か出ていておかしくないと思うのですが...

この回答へのお礼

鋭い洞察力に敬礼します。
しかしログを確認しても、変わった記録はありませんでした。
そこで、ログレベルが甘いのではと思い、ntp.confに、
logconfig =all
を追記し、ntpdを再起動
そして、再度ntpq -p; named stop; ntpq -p
のようにnamedの有無によるntpqの反応を確認してから、ログを確認してみましたが、新しいログは何もありませんでした。

そこで、しばらく放置でntpのログを観察してみました。
まずnamedを起動して、ログにsynchronizedが吐かれるのを確認。
そしてnamedを停止して、ログをしばらく観察。
しかし、その後ログの内容は変わらず、普通にsynchronizedを記録するだけでした。

namedを止めても動くという事は、おっしゃる通り名前情報をどこかしらにキャッシュしている事が考えられますが、namedが動いている時と止まっている時でログの違いは見当たりませんでした。

ログは次のような感じです。
4 Aug 17:51:57 ntpd[4136]: synchronized to 210.173.160.87, stratum 2
4 Aug 17:51:57 ntpd[4136]: kernel time sync status change 0001
4 Aug 17:51:57 ntpd[4136]: system event 'event_sync_chg' (0x03) status 'leap_none, sync_ntp, 3 events, event_peer/strat_chg' (0x634)
4 Aug 17:51:57 ntpd[4136]: system event 'event_peer/strat_chg' (0x04) status 'leap_none, sync_ntp, 4 events, event_sync_chg' (0x643)
--ここでnamedを停止--
4 Aug 17:57:24 ntpd[4136]: synchronized to 210.173.160.57, stratum 2
4 Aug 18:03:57 ntpd[4136]: synchronized to 210.173.160.27, stratum 2
うーん

お礼日時：2022/08/04 18:25

No.10 回答者： trka 回答日時： 2022/08/01 19:24

ご提示のログを参照しました。

29 Jul 14:08:53 ntpd[5974]: synchronized to 210.173.160.27...
29 Jul 14:17:30 ntpd[5974]: synchronized to 210.173.160.57...
の2行が同期成功を表し、サーバをIPアドレスで表していますがそれぞれntp1.jst.mfeed.ad.jpとntp2.jst.mfeed.ad.jpを意味していると受け取りました。
成功したときはIPアドレスで示し、失敗した時はドメインで表示する、の状態のようです。私個人的に、断定はもちろんできませんが名前解決ができなくなっているように感じられ、それがエラーメッセージに繋がっているように感じます。

●...ntp3は1度もsynchronizedのログが無く...
元々ntp1/ntp2サーバがご質問者様のパソコンに近いのだと思います。私もntpサーバを10台ほども指定していますが、一度も同期しないサーバは存在します。その事自体は不具合とは思われません。
●...サーバーは全て1024/377でした...
単位が分の時は(min)、1時間の場合は(h)と表示されます。
●...6時間以上同期しなかったり...
NTPサーバとの通信が不安定であることを示しているはずです。

問題はこのパソコンの電源が投入され同期を完了した後、エラーが発生するまでの時間は7月18日から7月29日までの11日間と思われますが、それだけ時間が立ってもpollが1024(sec)毎の同期要求が出されると考えると...

●ネットワークが(インターネット通信が)不安定。
●通信が不安定になるぐらいパソコンへの負荷が大きい。例えばメモリが少なくて常時ページングやスワップが発生している、なども要因に考えられます。
●ネットワークと言わず、DNSサーバは如何でしょうか。元々負荷の大きいDNSサーバに、一台だけしか指定されていない、などのことはないでしょうか。

私実は明日から2連休で、自宅のパソコンが2日間連続使用になります。自宅環境はwimax2で十分不安定な環境ですので、様子を探り木曜日にご報告しましょう。

この回答へのお礼

成功したらIPアドレス表記、失敗したら名前表記というのは、私も少し気になっていました。
途中で名前解決が失敗している可能性があるのですね。
しかしインターネットの名前解決は同マシン上で、キャッシング機能を有効にしたBINDに問い合わせているのですが、今回、時刻同期が停止した際は、BINDの再起動は行わず、ntpdを再起動しただけで、再び同期が始まりましたので、謎です。
poll項は、先ほど先生に教わって初めて確認したので、厳密に言うとpoll項確認時は、昨日ntpd再起動後1日しか経過していません。
それでもpoll1024はやはり異常でしょうか。
ネットワークが不安定と感じる事は、あまり無いですが、マシンが古いので、通信負荷が増えるとフリーズする事があります。
しかしその場合には、ネットワーク全体でDNSが使えなくなるので、すぐに気づき、マシンを再起動し、再起動後はインターネットもすいすい使えています。
古い機種なのでメモリは少ないかもしれません。
しかし、ごく一般的なデーモンしか起動していませんし、そこまでメモリを食う処理が思い当たりません。
現在は4ギガ中260メガしか使用されていませんでした。
DNSサーバーの負荷はどんなもんでしょうか。
DNSサーバーは1台ですが、ごく小規模なネットワークですので十分と考えているのですが・・・

貴重な2連休、お付き合い感謝します。
先生の環境で何か調査してくれるのですか。

お礼日時：2022/08/01 22:04

No.9 回答者： trka 回答日時： 2022/08/01 11:06

不思議ですね。

私も経験したことがありません。
●invalid host addressエラーが発生するのは"ntp2.jst.mfeed.ad.jp"に対してだけだろうか...それならば"ntp2.jst.mfeed.ad.jp"だけサーバから外してみたらどうだろうか。
●invalid host addressエラーの意味なのですが、DNSによる名前解決の後のIPアドレスが、NTPサーバとは関係ないIPアドレスのような...そんなことが起こっているような気もします...それならばNTPサーバの指定を直接にIPアドレスにしたらどうか。
●一度や二度同期に失敗しても、何故リトライを諦めてしまうのだろうか。私の記憶だけで誤ってるかもしれませんが、通常ntpq -pを実行し表示されるデータに、poll/reach項があり、pollは「サーバに何分ごとにアクセスするか。」ですし、reachは「直近の何度かのサーバアクセスに成功した割合。」を示したと思います。
今現在私のパソコンは全サーバに対し、pollが9h(9時間)、reachは377(取りこぼしなし)です。それに対しご質問者様の表示結果は、データ通信が不安定でreachが377に至らず、それ故pollも64secから変わらない...等の状態ではないでしょうか。

この回答へのお礼

補足では文字数の関係でログ内容を大幅に省略しましたが、より詳細には、
・・・
29 Jul 14:08:53 ntpd[5974]: synchronized to 210.173.160.27, stratum 2
29 Jul 14:17:30 ntpd[5974]: synchronized to 210.173.160.57, stratum 2
29 Jul 14:34:06 ntpd[2169]: getaddrinfo: "ntp1.jst.mfeed.ad.jp" invalid host address, ignored
29 Jul 14:34:06 ntpd[2169]: getaddrinfo: "ntp2.jst.mfeed.ad.jp" invalid host address, ignored
29 Jul 14:34:06 ntpd[2169]: getaddrinfo: "ntp3.jst.mfeed.ad.jp" invalid host address, ignored
のようにntp1とntp2で定期的にsynchronizedとなっていて、29日の14:34にntp1～3全てでinvalid host addressとなっていて、これは現状ntpq -pでstratum 16でない全てのサーバーです。
よく見るとntp3は1度もsynchronizedのログが無く29日にいきなりinvalid host addressとなっています。
NTPサーバの指定を直接にIPアドレスにする運用はIPアドレスの変更に対応できないため、最後の手段ですかね。
poll/reach項はstratum 16でないサーバーは全て1024/377でした。
pollは単位の表示が無く、単に1024となっていますが、これは1024分という事でしょうか。
1024分なら約17時間ですが、それにしてはログの間隔が合わない気がします。
しかも直近のntp2のログを見ると、
00:46:21
01:33:33
05:04:02
05:59:34
06:28:22
13:01:04
のように1時間以内に2度同期したり、6時間以上同期しなかったりと、等間隔ではありません。
今は正常に動いていますが、また同期が止まった際は、poll/reach項に注目してみます。

お礼日時：2022/08/01 18:06

No.8 回答者： wellow 回答日時： 2022/07/31 23:21

＞再起動すると直るので、何が原因か分かりません。

自分が絶対に正しいか、間違っているかでないと納得しないんですね。
呆れたので、私は手を引きますが、最後の回答は「あなたのその頑固さが原因」です。

この回答へのお礼

原因は未だ不明ですが、私の頑固さとntpdの挙動は無関係だと思います。。。
よって、引き続き詳しい方の助言を大募集中です。

お礼日時：2022/07/31 23:40

No.7 回答者： wellow 回答日時： 2022/07/31 22:59

＞invalid host address, ignored

その通りなんじゃないの？　ntpdが期待しているアドレスじゃなかったってこと。
犬の中身なんかしらないけど、ntpdがIPv4にしか対応していなくて、IPv6アドレスをもらったら、そういったエラーは吐きそうな気はする。

なので、＃３でもそれっぽいことは聞いている。

この回答へのお礼

再起動すると直るので、何が原因か分かりません。
今も問題なく動いているのですが、4～5日たつと、stratum 16になっています。
ですので定期的にntpq -pを実行してstratum 16になっていたらntpdを再起動するという、スマートでない運用しか思いつきません。

お礼日時：2022/07/31 23:15

No.6 回答者： wellow 回答日時： 2022/07/26 21:28

＞IP unreachableとはntpq -pの出力ですか。

いや、ntpqの出力にはそんなものはない。

＞設定は何も変更せずに

何も変更していないのか、何もしていないのかは、こちらでは分からない。だから推量するだけ。

＃５では、「ルーティング定義をルーティング関連の定義ファイルに手動追加したけど再起動していなかった」を疑ったもの。これであれば、確かに何もしていない。というか必要な作業をしていない。

この回答へのお礼

承知しました。

チョット日がたってしまいましたが、私の記憶が定かなら、設定の変更は本当に何もしていないのです。時刻の手動セットもしていません。
最初の回答が付いた時に、ほんの気まぐれで再起動してみたら、直ってしまったという状況です。
そして、今も問題なく動いています。
謎です・・・。

お礼日時：2022/07/26 21:51

No.5 回答者： wellow 回答日時： 2022/07/26 17:57

＃４

じゃ、再起動前はIP unreachableだったんじゃないの？

この回答へのお礼

IP unreachableとはntpq -pの出力ですか。
ntpq -pの出力は、全て質問文にコピペしました。
質問文を見返してみると、そのような表示は無いので、IP unreachableではなかったと思います。

ntpdは今も、問題なく動いています。
謎です・・・。

お礼日時：2022/07/26 18:17

No.4 回答者： wellow 回答日時： 2022/07/26 13:51

＞ntpdを再起動したら、いくつかのサーバーはstratum 2になりました。

・手動で実際に近い時間に合わせたとか、
・最初はslewモードだったけど、次はstepモードだったとか。

この回答へのお礼

ntpd再起動前は、約2分ものずれがありました。
手動で実際に近い時間に合わせる場合には、私の性格上おそらく電波時計を確認しながら±5秒ぐらいの時刻をセットするでしょうから、本件では手動でのセットはしていないと思われます。
slewモードとstepモードを使い分けた事はありません。slewモード、stepモードという言葉は、今知りました。
やはり謎です。

昔、ルーターが定期的に原因不明のフリーズを起こし、強制的に再起動する運用がありましたが、今、その感覚です^^;

お礼日時：2022/07/26 14:17