В наших 3 Linux-ящиках centos 7.1 мы увидели в журналах сообщения ниже, а затем служба ntpd была остановлена, так как смещение больше 1000 с.
systemd: время было изменено
ntpd[2626]: 0.0.0.0 0617 07 panic_stop -26789 s; set clock manually within 1000 s.
Все эти 3 бокса linux находятся под машиной ESX. Также обратите внимание, что многие другие Linux-боксы находятся на той же машине ESX, кроме этих Linux-боксов.
У нас есть внешние серверы NTP, настроенные в этих ящиках, и никаких проблем с этими серверами ntp нет.
Учитывая вышеупомянутый сценарий, каковы возможности изменения системных часов помимо ручного вмешательства, поскольку эта проблема вызвала автоматическую остановку службы NTP.
Умозрительный ответ: бортовые часы могут дрейфовать при отключении электроэнергии. Возможно, бортовой аккумулятор почти разряжен. Если питание машины на какое-то время отключено, то время, установленное при перезагрузке, может выходить за пределы максимально допустимой настройки ntpd.
Если вы работаете на виртуальных машинах, тогда необходимо контролировать только службу на сервере виртуальных машин.
В настоящее время у меня есть машина CentOS 7.1 (не виртуальная машина). . . В течение этого месяца было отключено 47мин + 57мин + 1день7мин + 2мин. В машинном отделении были выполнены некоторые электромонтажные работы. Посмотрите на 'последняя перезагрузка выключения -x':
[root@boxymcboxface ~]# last -x shutdown reboot
reboot system boot 3.10.0-229.el7.x Sun Jan 15 16:41 - 16:43 (8+00:02)
shutdown system down 3.10.0-229.el7.x Sun Jan 15 16:38 - 16:41 (00:02)
reboot system boot 3.10.0-229.el7.x Sun Jan 15 16:16 - 16:38 (00:22)
shutdown system down 3.10.0-229.el7.x Sat Jan 14 09:09 - 16:16 (1+07:07)
reboot system boot 3.10.0-229.el7.x Fri Jan 13 12:18 - 09:09 (20:50) ** first ntpd panic_stop seen @ Jan 13 12:38:39 **
shutdown system down 3.10.0-229.el7.x Fri Jan 13 11:21 - 12:18 (00:57) ** down for 57 mins **
reboot system boot 3.10.0-229.el7.x Tue Nov 22 11:49 - 11:21 (51+23:31)
shutdown system down 3.10.0-229.el7.x Tue Nov 22 11:02 - 11:49 (00:47)
Первое сообщение panic_stop:
ntpd[733]: 0.0.0.0 c617 07 panic_stop -1027 s; set clock manually within 1000 s.
Было бы интересно посмотреть, какие часы устанавливаются после каждой перезагрузки. Но видно только последнее сообщение. 'dmesg | grep clock':
[ 0.810823] rtc_cmos 00:08: setting system clock to 2017-01-15 16:40:57 UTC (1484498457)
Таким образом, похоже, что в течение 57 минут, когда, возможно, питание было отключено на ~ 30 минут ~ часы отключались (слишком быстро) на 17 минут.
Виртуализация очень подвержена дрейфу часов. ЦП может делать только одну вещь за раз, поэтому отслеживать время для многих машин довольно сложно.
Вот лучшие практики для учета времени в VMWare: http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006427