web-dev-qa-db-ja.com

ログのカーネル警告：set_rtc_mmssは0から58に更新できません

私はこれらのログメッセージをたくさん見てきました

Jan 3 00: 58: 57 foo kernel: set_rtc_mmss: can't update from 0 to 58

VMwareで実行されているCentOS 6.4 VMで発生します。ゲストOSでハードウェアクロックが正しく設定されていないことが原因であると理解しています。ハードウェアクロックを現在のシステム時刻に設定する次のコマンドを見つけました。

Sudo hwclock --systohc

これは仮想マシンの正しい設定ですか？また、これを永続化できるようにどこに設定できますか？カーネルのブートパラメータでは？新しくプロビジョニングされたVMでこの問題が発生しないようにしたいと思います。

UPDATE 1

要求通り：

me@foo:~> ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 LOCAL(0)        .LOCL.          10 l   43   64  377    0.000    0.000   0.000
+dtc-nist01.ntp. .ACTS.           1 u  174 1024  377    3.311   -8.554   0.497
*nist1-nj.ustimi .ACTS.           1 u  205 1024  377    6.737    3.775   0.433
+nist1-pa.ustimi .ACTS.           1 u   55 1024  377    8.610    4.688   0.337

このVMではvmwaretoolsが古くなっています。おそらく、vmwaretoolsのインストールを管理するためのpuppetモジュールが適切にインストールしなかった可能性があります。確認してからご連絡いたします。

更新2

はい、VMwareツールがインストールされており、最新バージョンです。

me@foo:~> ps aux | grep vmtools
root     56021  0.0  0.1  59508  4156 ?        S    Jan09   3:29 /usr/sbin/vmtoolsd

更新3

VMで「ゲストの時刻をホストと同期」を有効にしてみました。

me@foo:~> vmware-toolbox-cmd timesync status
Disabled
me@foo:~> vmware-toolbox-cmd timesync enable
me@foo:~> vmware-toolbox-cmd timesync status
Enabled

しかし、私はまだそれらのメッセージを受け取っています。実際、dateとhwclock --showは数分離れていますが、以前はかなりきついでした。

以前は、古いSLES 9 VMはVMware記事 Linuxゲストのタイムキーピングのベストプラクティス の設定の恩恵を受けていましたが、CentOS/RHEL 6ゲストには追加のカーネルパラメーターセットは必要ないと述べています。

UPDATE 4

CentOS 6.5へのアップグレードは役に立ちませんでした。カーネルは次のとおりです。

Linux foo 2.6.32-431.1.2.0.1.el6.x86_64 #1 SMP Fri Dec 13 13:06:13 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
centosvmware-esxivirtual-machines
6
Banjer

私が読んだ他のすべてに基づいて、特にサーバーのdateが問題ない場合、これらの警告は害がないように聞こえます。少し面倒ですが。

私はntp.orgからのこの一口に私を安心させます：

あたり http://www.ntp.org/ntpfaq/NTP-s-trbl-spec.htm#Q-LINUX-SET-RTC-MMSS ：

8.3.4.1.1。 set_rtc_mmss：ca n't update from 54 to 5はどういう意味ですか？

関数set_rtc_mmss（）は、システム時刻からCMOSクロックの分と秒を更新します。タイムゾーンの問題を回避するために時間または日付を更新しません。[1]表示されるメッセージは、すべての時間の更新が成功するわけではないという問題を認識しているユーザーと実装者。

CMOSクロックがすでに18:03:45にある間、システム時刻が17:56:23であると想像してください。分と秒だけを更新すると、ハードウェアクロックが18:56:23に設定されます。値が正しくありません。この問題の解決策は、数分待つか、問題を修正するカーネルパッチをインストールすることです。通常、ハードウェアクロックの誤った時刻は、再起動後、またはAPMがスローダウンするまで表示されませんシステム。

1
Banjer

VMWareは、ゲストOSでntpクライアントを構成する方法に関する知識ベースにいくつかの提案をしています。 ntpで時刻を更新するだけなので、最初にvmware-toolbox timesyncが無効になっていることを確認します。

から Linuxゲストのタイムキーピングのベストプラクティス ：

これは彼らのサンプルです/etc/ntp.conf：

tinker panic 0
restrict 127.0.0.1
restrict default kod nomodify notrap
server 0.vmware.pool.ntp.org
server 1.vmware.pool.ntp.org
server 2.vmware.pool.ntp.org
driftfile /var/lib/ntp/drift

最初の行（tinker panic 0）は大きな時間のジャンプを可能にします。 （例：システム状態が保存/復元された）

別の方法としては、ゲストのntpを無効にし、vmware-toolsの時刻同期を有効にすることです。

2
basvdlei

CentOS 6.4の最新のカーネルバージョンを実行していますか？ clocksource = acpi_pmで起動してみます。また、ntpdate -u tick.usno.navy.mil && hwclock --systohcを実行して、問題を解決します。問題が解決しない場合は、divizor = 10も追加します。

正直なところ、問題の一部は、リアルタイムクロックの設定と読み取りを行う特定のカーネルのコードに関係していると思います。それがエラーメッセージの原因です。もう1つの原因は、仮想時間割り込みが十分に定期的に配信されていないか、タイマー割り込みハンドラーがカーネル時間を正しくスケーリングしていないことです。これが、クロックドリフトの原因です。

残念ながら、ntpをより攻撃的にすることは、問題の松葉杖にすぎません。

新しいカーネルはありますか？それはあなたの最も安全な賭けかもしれません。幸運を。

2
etherfish
  1. BIOSから起動
  2. システムの日付と時刻を確認します（必要に応じて現在の日付に修正します）
  3. Esc（終了して変更を承認）

それはうまくいくはずです

0
SRK