同期された多数のマシンを備えたNTPサーバーで時間を修正する方法
NTPサーバーの時刻設定が間違っていて7時間先です（タイムゾーンはマシンの出荷後に変更されましたが、時刻は変更されていません）。サーバー自体は同期されていませんが、ローカルクロックがあります。このサーバーでは、10を超えるクライアントがクロックを同期しているため、サーバーのグループ全体が間違った時刻になっています。
NTPサーバーで、修正がスルーされ、すべてのクライアントも修正される時間を変更するにはどうすればよいですか？最初に、クライアントに許可する「dateMMDDhhmm」を介した修正だけでテストしました。サーバーから切断します（ntpqのサーバー名の前のアスタリスクが消えました）。
クロックを7時間戻し、システムに将来のファイルを持たせることで、すべてのサーバーの時刻を手動で変更した場合、同期されたすべてのサービスがどのように動作するかわかりません。クラッシュが発生する可能性があり、システムはファブプロダクションにサービスを提供します。
あなたが時間を回転させることについて話すとき、あなたは通常少しの時間について話します。修正は、adjtime()を呼び出すか、Linuxではadjtimex()を呼び出すことで実行されます。
Ntpdのマニュアルページから：
-x Normally, the time is slewed if the offset is less than the step
threshold, which is 128 ms by default, and stepped if above the
threshold. This option sets the threshold to 600 s, which is
well within the accuracy window to set the clock manually.
Note: Since the slew rate of typical Unix kernels is limited to
0.5 ms/s, each second of adjustment requires an amortization
interval of 2000 s. Thus, an adjustment as much as 600 s will
take almost 14 days to complete. This option can be used with
the -g and -q options. Note: The kernel time discipline is dis‐
abled with this option.
この速度で7時間の修正が行われるのを待ちたいとは思わないでしょう。 1年以上かかります。 Linuxでは、32ビットシステムのadjtimeは、約2000秒のデルタに効果的に制限されます。 64ビットシステムはおそらくそれを問題にしませんが、変更が有効になる速度は依然として懸念事項です。
したがって、Linuxの実装にはしきい値があり、おそらく他のしきい値では、非常に遅い「スルー」が発生しますが、これを超えると、マスターとクライアントのシステムクロックがステップされ、はるかに速く進むことができます。
マスターとクライアントの時間差が大きすぎる場合、クライアントがエラーを想定して更新しないという別のしきい値もあります。 ntpdのマニュアルページから：
-g Normally, ntpd exits with a message to the system log if the
offset exceeds the panic threshold, which is 1000 s by default.
This option allows the time to be set to any value without
restriction; however, this can happen only once. If the thresh‐
old is exceeded after that, ntpd will exit with a message to the
system log. This option can be used with the -q and -x options.
-gオプションはほぼ確実にデーモンに設定されていないことに注意してください。これは通常、ntpd -gqとして使用されるか、システムの起動時に1回限り実行されるか、手動でntpdateのように動作します。ただし、パニックのしきい値はコンパイル時に構成できると思われるため、OSベンダーのマニュアルページを確認してください。
選択した調整の頻度とサイズを使用して一連の時間調整を行うプログラムを作成するのは非常に簡単です。これはntpマスターで実行でき、調整された時間をクライアントに提供しますが、クライアントシステムが受け入れる最大サイズ調整と、クライアントシステムが非常に遅いスルーを実行する原因となる最小しきい値を知る必要があります。安全のために、クライアントシステムでのntp実装を調査する必要があります。
-xオプションを使用せずにLinuxのデフォルトのntpdと同様の特性を持つシステムを更新する場合は、5秒ごとに0.5秒の調整を行うなどの体制を使用でき、約3日。 2番目の境界を超えない1秒未満の調整を行うと、cronジョブを2回トリガーするなどの回避に役立つ場合がありますが、何らかの副作用が見つかる可能性があります。
サーバーがすべて互いに同期しなくなった状況に陥ると、混乱します。可能であれば、時差を監視し、一部のサーバーがフォローしなくなった場合は自動定期更新の実行を自動的に停止し、アラートを生成したいと思います。
ご存知のように、クロックの変更が短い間隔内にある場合、クライアントは同期されたままになります。一部のシステムでは、これはわずか5分です。あなたは10分かもしれません。あなたはその間隔内で時計をジャンプすることができ、クライアントは追跡するためにスルーします。
私は4つのオプションを見ることができます：
何もせず、間違った時間で無期限に生きます。
時計を4分（または600秒間隔の場合は9分）リセットし、その年の間にad nauseumを繰り返します mc0e has 計算が必要です 。あなたは本当にスクリプトでこれをしたいと思うでしょう。今年のほとんどの期間、不正確な時間を考慮してください。生産レポートと相関させるために、時間オフセットを十分にメモしてください。
サーバーを7時間のメンテナンス期間（クリスマスの日、誰か？）停止し、すべての時計を一度に適切に修正します。
時計をジャンプして、7時間のレポートの重複があることを全員が知っていることを確認します。ただし、これらの同じ人々は、生産時間が7時間ずれていることをすでに知っているはずなので、これは許容できると思うかもしれません。 （明らかに、これがファブプロセスにどのような影響を与えるかはわかりません。）
どのソリューションも理想的ではありません。生産報告時間が重要な場合、オプション2はおそらく最悪の悪い束です。