Linuxシステムで特定の時間関連プログラム(ntpd
など)が実行されている場合、カーネルはいわゆる「11分モード」に切り替わります(hwclock
のマニュアルページを参照)。 11分ごとにシステムクロックからハードウェアクロックを自動的に更新します。
SLES11では、ハードウェアクロックをシステムクロックより10時間遅れるように設定した場合、11分のモードではハードウェアクロックをシステムクロックに合わせることができないように見えることが経験的にわかっています。しかし、システムクロックより5分遅れてハードウェアクロックを設定した場合、11分モードは完全に一致します。
明らかに、11分のモードで処理できる最大の更新がいくつかあり、それが何であるか疑問に思っています。
更新:
これは変だ...
さらに実験をすると、システムクロックより約20分遅れてHWクロックがある場合、11分モードではHWクロックがexactly30分になるように設定されます。システムクロックの後ろ(!):
# date
Tue Dec 6 10:16:52 EST 2011
# hwclock --set --date "12/6/11 09:56"
#
# date
Tue Dec 6 10:17:16 EST 2011
# hwclock --show
Tue Dec 6 09:56:06 2011 -0.156551 seconds
#
# date
Tue Dec 6 10:23:09 EST 2011
# hwclock --show
Tue Dec 6 10:01:58 2011 -0.535772 seconds
#
# date
Tue Dec 6 10:34:28 EST 2011
# hwclock --show
Tue Dec 6 10:04:27 2011 -0.192025 seconds
更新:
私はこれに遭遇しました: https://bugs.archlinux.org/task/27408 これは、ハードウェアクロックの時刻が遠すぎる場合、カーネルがハードウェアクロックを更新しないことを意味しますシステムクロック時間から。
RHEL 4.6のhwclock
manページから:
This mode (we'll call it "11 minute mode") is off until something turns it on. The ntp
daemon xntpd is one thing that turns it on. You can turn it off by running
anything, including hwclock --hctosys, that sets the System Time the old fashioned way.
To see if it is on or off, use the command adjtimex --print and look at the value of
"status". If the "64" bit of this number (expressed in binary) equal to 0, 11 minute mode
is on. Otherwise, it is off.
そのため、hwclock --set
を実行しているおかげで、おそらく無効になっています。同じように、adjtimex --print
の出力を確認して確認できます。
実際、これはカーネルの11分モードとは関係ありません。これはntpdの機能に関連しています。
Ntpのいわゆる正気度制限を知っていますか?時間が遠すぎる(たとえば10時間)場合、ntpdはあきらめ、クロックをスキューしません。このような場合、ntpdまたはntpdateは手動で実行する必要があります。 -g
のNtpdオプションはそれを行うべきです。 manページから情報を確認してください:
カーネルは、11分モードで60分以上オフになっていると、時刻を同期しません。これはSUSE Enterpriseの一般的な問題です。詳細については、Open SUSEの記事を参照してください: https://lists.opensuse.org/opensuse-bugs/2011-06/msg01348.html