Я видел кучу этих сообщений журнала
Jan 3 00: 58: 57 foo kernel: set_rtc_mmss: can't update from 0 to 58
Они возникают на виртуальных машинах CentOS 6.4, работающих на VMware. Я понимаю, что это как-то связано с неправильной настройкой аппаратных часов в гостевой ОС. Я нашел эту команду, которая устанавливает аппаратные часы на текущее системное время:
sudo hwclock --systohc
Это правильный параметр для виртуальной машины? Кроме того, где это можно настроить, чтобы оно было постоянным? В параметрах загрузки ядра? Я бы хотел, чтобы на вновь подготовленных виртуальных машинах не было этой проблемы.
ОБНОВЛЕНИЕ 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
Я вижу, что vmwaretools на этой виртуальной машине устарела. Возможно, у меня есть марионеточный модуль для управления установкой vmwaretools, который не установил его должным образом. Я посмотрю и вернусь к вам.
ОБНОВЛЕНИЕ 2
Да, инструменты vmware установлены и имеют последнюю версию.
me@foo:~> ps aux | grep vmtools
root 56021 0.0 0.1 59508 4156 ? S Jan09 3:29 /usr/sbin/vmtoolsd
ОБНОВЛЕНИЕ 3
Я попытался включить «Синхронизировать гостевое время с хостом» на виртуальной машине:
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 использовались настройки, указанные в статье о VMware. Лучшие практики хронометража для гостей Linux, но в нем говорится, что гостям CentOS / RHEL 6 не требуется установка дополнительных параметров ядра.
ОБНОВЛЕНИЕ 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
Вы используете последнюю версию ядра для CentOS 6.4? Я бы попробовал загрузиться с clocksource = acpi_pm. Кроме того, я бы сделал ntpdate -u tick.usno.navy.mil && hwclock --systohc и оставил все как есть. Если все будет продолжаться, добавьте также divizor = 10.
Честно говоря, я подозреваю, что проблема частично связана с кодом в вашем конкретном ядре для установки и считывания часов реального времени - именно поэтому вы получаете сообщение об ошибке. Другая часть связана с тем, что прерывания виртуального времени не доставляются достаточно регулярно или обработчик прерывания таймера не масштабирует время ядра правильно - и это то, что вызывает дрейф часов.
К сожалению, заставить ntp быть более агрессивным - это всего лишь костыль для решения проблемы.
Доступно ли вам более новое ядро? Это может быть ваша самая безопасная ставка. Удачи.
У VMWare есть несколько предложений в базе знаний о том, как настроить ntp-клиент в гостевой ОС. Прежде всего, убедитесь, что временная синхронизация vmware-toolbox отключена, так как вам нужно только, чтобы ntp обновлял время.
Из Лучшие практики хронометража для гостей 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.
Судя по всему, что я прочитал, эти предупреждения кажутся безобидными, особенно если 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: cannot update from 54 to 5?
Функция set_rtc_mmss () обновляет минуты и секунды CMOS-часов по системному времени. Он не обновляет час или дату, чтобы избежать проблем с часовыми поясами. [1] Показанное сообщение было добавлено, чтобы пользователи и разработчики знали о проблеме, что не все обновления будут успешными.
Представьте, что системное время - 17:56:23, а часы CMOS уже показывают 18:03:45. При обновлении минут и секунд аппаратные часы будут установлены на 18:56:23, что является неправильным значением. Решение этой проблемы - либо подождать несколько минут, либо установить исправление ядра, которое устраняет проблему. Обычно неправильное время на аппаратных часах не отображается до перезагрузки или, возможно, после того, как APM замедлит вашу систему.
Это должно работать