Linuxシステムの時間は一時的にジャンプします

11

一部の（ハードウェア）サーバーで奇妙なシステム時刻の変更動作を見ました。次のように/var/logs/syslog、各ログメッセージの前の日付時刻が時々ランダムに変わり、次のメッセージで通常に戻ります。

Feb 22 2018 09:09:30 ...  
Feb 22 2018 09:09:32 ...  
Jan 13 2610 15:37:42 ...  
Feb 22 2018 09:09:33 ...  
Feb 22 2018 09:09:34 ...

例のように、日付時刻の突然の変化は、何百年も離れている可能性があります。

奇妙なタイムスタンプを持つログメッセージが特定のプロセスからのものではないことを確認できます。それは、すべてのプロセスでランダムに発生する可能性があります。

また、2つの異常な時間の変化の間の期間は数分から数時間の間で変化します（ただし、異常な時間の変化はより頻繁に発生する可能性がありますが、ログの書き込みが毎秒行われないため、それらの多くはsyslogに表示されません）。

また、複数のサーバーで発生するので、ハードウェアの問題ではないと思います。

サーバーに関する詳細：1つのコントローラーといくつかの計算ノードを備えたOpenStackインストールです。各サーバーでntpサービスが実行されています。コントローラーは、それ自体のハードウェアクロックから時間がかかるように構成され、計算ノードサーバーは、コントローラーからの時間を同期します。各サーバーには独自のペースで異常な時間の変化があることに注意してください。「間違った時間」はコントローラーからntpを介して同期されていないようです。

計算ノード上のゲストシステム（仮想マシン）がホストシステムの時間に影響を与える可能性があると考えていました。しかし、これは、仮想マシンを実行していないときにコントローラーに同じ問題がある理由を説明できません。

検出する方法が必要です。システム時刻を変更したのは誰ですか、どのように発生しますか

logs timestamps time

— 趙楊
ソース

表示されているタイムスタンプは実際のタイムスタンプですか？表示する例は他にありますか？

— Kusalananda

問題のサーバーはブレードサーバーですか？その場合、ブレードシャーシ管理ユニットが個々のサーバーブレードのクロックを同期しようとしている可能性があります。クロックハードウェアの既知のバグを調べるには、実際のサーバーモデルを知る必要があります。

— telcoM 2018

HW時間も監視できますhwclockか？それがその時にも変化する場合...

— Jaroslav Kucera

3

syslogdは、任意のプロセスから送信されたメッセージの内容を適切なログファイルに書き込むだけであることに注意してください。タイムスタンプは実際にはメッセージ内で送信され、syslogdによって生成されません。おそらく何かがメッセージを破損しているか、またはそれが1つのタイプのプロセスである場合、おそらくそのプロセスはバグのあるsyslogメッセージを送信しています。参考までに、フォーマットはRFC3164で説明されています。日付/時刻部分はプレーンASCIIで送信されます。

— wurtel

質問のsuperuser.com/questions/1298404 にある複数投稿された複製のすべての情報を入力してください。

— JdeBP 2018

1

関連する側面は、カーネルバージョンと、ブートプロセスの初期の次の行です。

kernel: Fast TSC calibration using PIT
...
kernel: Calibrating delay loop (skipped), value calculated using timer frequency..
...
kernel: Switching to clocksource tsc

YMMVおよびTSCまたはPITを使用していない可能性があります

これは、少なくとも1つのCPUのクロックが同期していないために発生しているバグである可能性があります。

これを実行することで簡単に確認できます：

for cpu in {0..8} ; do taskset -c $cpu date ; done

これはdate、各CPUに対して実行されます（最大8コア/スレッドがあると想定）。私の推測が正しい場合は、CPUの1つが常に間違った時間を持つことになります。

その場合は、まずカーネルをアップグレードしてみてください。それがうまくいかない場合は、clocksourceブートパラメータをいじってください（そうであると仮定x86-64）。

clocksource=    Override the default clocksource
                Format: <string>
                Override the default clocksource and use the clocksource
                with the name specified.
                Some clocksource names to choose from, depending on
                the platform:
                [all] jiffies (this is the base, fallback clocksource)
                [ACPI] acpi_pm
                ...
                [X86-64] hpet,tsc

これの出力も参照してください：

cat /sys/devices/system/clocksource/clocksource*/available_clocksource

— V13
ソース

0

コントローラサーバーのハードウェアクロックは、時間に関する安定した情報源ではないようです。コントローラのタイプをより信頼性の高い原子時計と同期するように設定する必要があります。

これは、ハードウェアクロックを更新するために使用できるコマンドです。 hwclock -s

以下も参照してください。

   -s, --hctosys
          Set the System Time from the Hardware Clock.

          Also set the kernel's timezone value to the local timezone as indicated by the TZ environment variable and/or /usr/share/zoneinfo, as tzset(3) would interpret them.  The obsolete tz_dsttime field of the kernel's time‐
          zone value is set to DST_NONE.  (For details on what this field used to mean, see settimeofday(2).)

          This is a good option to use in one of the system startup scripts.

   -w, --systohc
          Set the Hardware Clock to the current System Time.

— ドミトリ・クプ
ソース

0

コピー元：CRONメッセージがsyslogで任意の長時間遅延している：

要するに、私が使用しているrsyslogのバージョンにバグがあり、それが受け取ったsyslogメッセージを任意の時間遅延させます。バグレポートはこちら。また、rsyslogをアップグレードすると問題が解決しました。CRONのせいではありません。

— 趙楊
ソース

-1

このような異常を回避するには、ストラタム1または2のソースに同期した外部NTPサーバーを使用する必要があります。ハードウェアクロックは信頼できません。

— 酸素
ソース