Какой список ntp серверов правильный на данный момент? Убегает время!

Вряд ли это удалённый сервер. Проверь все 4 через

ntpdate -q $host

1) Возможно, какой-то серьёзный косяк в настройке твоего ntpd. Плюс аппаратные часы твоего хоста работают с немного неправильной скоростью ( это нормально )

По идее, одскульный ntpd, как и хипстерский chronyd, умеет вычислять дельту скорости аппаратных часов, и сами корректируют время с учётом такого убегания

2) но скорее всего, у тебя не сервер, а виртуалка. И включен какой-либо механизм синхронизации времени виртуалки с временем сервера. И на сервере время убежало вперёд на 20 секунд.

cron ведёт лог, а механизм синхронизации с хост-системой - нет

http://support.ntp.org/bin/view/Servers/StratumTwoTimeServers

«2) но скорее всего, у тебя не сервер, а виртуалка. И включен какой-либо механизм синхронизации времени виртуалки с временем сервера. И на сервере время убежало вперёд на 20 секунд.»
Да! На сервере запущена виртулка в openvz контейнере и в нем крутится ntpd. У виртуалки ovz в конфиге есть опция CAPABILITY=«SYS_TIME:on»
ЛУчше перенести ntpd из виртуалки на хостовый linux?
До 21 сентября были проблемы со временем - но крайне редко. т.е. такая конфигурация (ntpd в виртуалке) «стабильно» работала долгое время.

внезапно синхронизатор от systemd справляется с этой задачей куда лучше ntpd.

centos5 у меня

ЛУчше перенести ntpd из виртуалки на хостовый linux?

Как бы да.

Для начала нужно настроить синхронизацию времени на стороне хост системы. И/или отключить синхронизацию контейнера с хост-системой

А решение о переносе контейнера на железо принимается исходя из задач

внезапно синхронизатор от systemd справляется с этой задачей куда лучше ntpd.

Не пора ли вообще уже всё остальное выкинуть ? А то с логами справляется, с настройкой сети справляется, с кучей всего справляется. systemd запустил - и ничего не нужно. :-)

Ну с синхронизацией действительно лучше справляется, в тех случаях, когда железные часы глючат, особенно.
Насчет остального - дело вкуса.

Может кто то знает - почему время в openvz виртуалке отстает от времени в хосте?
И как объяснить следующее. В только что стартанутой ovz виртуалке время уже отстает, как и в виртуалке, которая работает продолжительное время.Как такое может быть?
Как поможет перенос ntpd из виртуалки в хостовый linux в этом случае?

0.ru.pool.ntp.org
1.ru.pool.ntp.org
2.ru.pool.ntp.org
3.ru.pool.ntp.org

Может кто то знает - почему время в openvz виртуалке отстает от времени в хосте?

Я не могу: я такого не видел пока.

Как поможет перенос ntpd из виртуалки в хостовый linux в этом случае?

Просто зачем лишний ненужный процесс в виртуалках, если можно иметь один в хост-системе ?

«Просто зачем лишний ненужный процесс в виртуалках, если можно иметь один в хост-системе ?» в общем случае согласен
ps
Хотя на просторах интернет пишут что ntpd и в отдельную ovz виртуалку имеет смысл выносить.

Хотя на просторах интернет пишут что ntpd и в отдельную ovz виртуалку имеет смысл выносить.

Если только с целью безопасности, и только в одну. Это если можно синхронизировать саму хост-систему из контейнера. Других причин я не представляю пока.

# hwclock;date;vzctl exec 203 date;vzctl exec 206 date;vzctl exec 212 date
Mon 25 Sep 2017 10:04:33 AM MSK  -0.779054 seconds
Mon Sep 25 10:04:33 MSK 2017
Mon Sep 25 10:04:33 MSK 2017
Mon Sep 25 10:04:33 MSK 2017
Mon Sep 25 11:04:09 MSK 2017

!!! время в виртуалке 212 (последняя строка) на часы в принципе можно не смотреть. но секунды отстают. После ребута виртуалки 212 картина с ее временем не меняется.

Посмотрел на всякий случай. Так вот, кстати, удобнее:

vzlist | awk '{print $1}'| grep "^[0-9]" | xargs -I {} vzctl exec {} date

Даже не знаю, что и сказать. Было подумал о каком-то непонятном /etc/localtime, но потом ещё раз подумал. Тогда бы и ntpd смещение не заметил. Разве что несколько разных localtime в разных chroot внутри этого контейнера. Больше ничего в голову не приходит.

Для hvm типа квм, ксен, вмваре и тд. Рекомендуется устанавливать свои нтп демоны внутри вм. Идеально если в своей сети будет свой нтпд на железе в качестве сервера.

При массовых миграциях и фриза машин зачастую возникает большая дельта. Которую сама машина не подвинет. Нтпд через некоторое время может убрать этот спайк. Я зачастую просто ансиблом по всем живым машинам передергиваю нтпд и вопрос решен. Можно закронить нтпдейт.

На итернет хостинге вообще надеяться на правильное время и тайм зону на хосте не приходится. И время появления спайков при миграциях, бекапвх вообще не угадать. Там навкрнок самое надежное будут ежечвсные нтпдейты в кроне

Для hvm типа квм, ксен, вмваре и тд.

Только у него OpenVZ, а это всё меняет в корне.

закронить нтпдейт на доверенный сервер не помешает.

что такое «ансиблом»?)

Может кто то знает - почему время в openvz виртуалке отстает от времени в хосте?

Потому что твоя виртуалка синхронизируется при старте с ntp-сервером, время которого отличается от времени хоста на 20 секунд. А хост - не сихронизируется или синхронизируется с каким-то другим ntp-сервером.

Это хороший, годный список. Не меняй его.

какой список ntp серверов лучше использовать?
Сейчас такой

server ntp1.vniiftri.ru
server ntp2.vniiftri.ru
server ntp3.vniiftri.ru
server ntp4.vniiftri.ru

Это хороший, годный список. Не меняй его.

Вообще-то, это не очень годный список, так как все сервера в одном месте. К нему не повредит добавить хотябы по одному иркутскому и хабаровскому серверу:

ntp1.niiftri.irkutsk.ru
vniiftri.khv.ru

http://vniiftri.ru/index.php/ru/services/22-ntp

как Вы это увидели?
в виртуалке своего ntpd нет, ntpdate не запускается при старте виртуалки.
Перенес ntpd из виртуалки в хост. Хост синхронизируется сейчас со списком серверов (stratum 2)

Может кто то знает - почему время в openvz виртуалке отстает от времени в хосте?

«system clock» vs «hardware clock»

Просто запустить ntp сервер мало, нужно ещё сказать ему синхронизировать аппаратные часы

Указывается в настройке ntp сервера. Проверить можно через hwclock

а как называется эта (для синхронизации аппаратных часов) настройка ntp сервера?

а как называется эта (для синхронизации аппаратных
часов) настройка ntp сервера?

Вроде как, никак не называется. Вроде бы, ни один ntp-сервер этого не делает. Это делает или hwclock, или ядро. В первом случае hwclock запускают кроном с соответствующим параметром. Второй случай несколько более запутан. Он зависит от версии (даже типа) ntp-сервера и от версии ядра. Достоверно не скажу, но на пальцах это выглядит так. ntp-сервер активирует нечто в ядре (ntpd это делает, openntpd не умеет, остальные смотреть самостоятельно), после чего ядро начинает корректировать RTC. До определённой версии у ядра было ограничение на интервал коррекции, потому большое смещение не корректировалось. С какой-то версии ограничение то ли убрали, то ли сделали большим. OpenVZ ядро старое (если речь не про 3.x - тут не знаю), так что там интервал маленький, сколько-то минут (может, десятков).

Не пора ли вообще уже всё остальное выкинуть ?

Мы работаем над этим. :)

Вроде бы, ни один ntp-сервер этого не делает. Это делает или hwclock, или ядро.

Да, я был неправ. https://serverfault.com/questions/337930/what-is-the-largest-hardware-clock-u...

Тогда остаётся только проверять через «hwclock --show» и «ntpdate -q» и , где и какая синхронизация работает

Вот, нашёл про ядро и RTC:

https://lists.altlinux.org/pipermail/community/2014-March/681844.html

проблема то не найдена на самом деле
с чего все началось - в одной из виртуалок того же сервера падал dovecot (проблема известная, падает если время в системе вдруг изменилось более чем на 5сек по моему)
Прошу обратить внимание на первоначальный пост, это логи виртуалки c ntpd, время убегало аж на 20сек за 75минут. И в момент когда ntpd писал в лог «time reset -20.241688 s» падал dovecot в соседней виртуалке. Виртуалке с ntpd было разрешено менять время в основной системе.
На данный момент запущено два ntpd один в хосте и один в виртуалке (openvz опцию в виртуалке которая разрешает менять время в ядре убрал) и вторые сутки все в норме, ntpd который в хосте и в вртуалке в логах пишут про расхождение времени «time reset -0.397007 s» и в каждой такой строчке расхождение не более 1сек. бывают моменты что дельта в логах ntpd серверов совпадает
Вот и не пойму в чем дело то было, понимаете какой вопрос.
В виртуалке в которой ntpd запущен работает еще система биллинга, могло ли быть такое - что в момент появления диких рассинхронов времени (см лог) запущенный ntpd как бы замерзал внутри высоконагруженной виртуалки и по причине нехватки ресурсов CPU тормозил на 20 и более сек?
Еще интересное в логах ntpd, смотрите на дату

19 Sep 11:42:48 ntpd[23566]: synchronized to 95.104.192.10, stratum 2
19 Sep 11:59:32 ntpd[23566]: synchronized to 91.207.136.50, stratum 2
19 Sep 12:01:22 ntpd[23566]: time reset -116.225516 s
19 Sep 12:05:42 ntpd[23566]: synchronized to LOCAL(0), stratum 10
19 Sep 12:06:21 ntpd[23566]: synchronized to 93.180.6.3, stratum 2
19 Sep 12:12:04 ntpd[23566]: synchronized to LOCAL(0), stratum 10
19 Sep 12:56:00 ntpd[23566]: synchronized to 91.207.136.50, stratum 2
19 Sep 13:11:22 ntpd[23566]: time reset -116.493058 s
19 Sep 13:15:39 ntpd[23566]: synchronized to LOCAL(0), stratum 10
19 Sep 13:15:47 ntpd[23566]: synchronized to 91.207.136.50, stratum 2
19 Sep 13:21:06 ntpd[23566]: synchronized to 95.104.192.10, stratum 2
19 Sep 13:22:13 ntpd[23566]: synchronized to LOCAL(0), stratum 10
19 Sep 14:07:02 ntpd[23566]: synchronized to 95.104.192.10, stratum 2
19 Sep 14:39:12 ntpd[23566]: time reset -116.760560 s
19 Sep 14:43:20 ntpd[23566]: synchronized to LOCAL(0), stratum 10
19 Sep 14:43:41 ntpd[23566]: synchronized to 93.180.6.3, stratum 2
19 Sep 14:44:23 ntpd[23566]: synchronized to 91.207.136.50, stratum 2
19 Sep 14:50:48 ntpd[23566]: synchronized to LOCAL(0), stratum 10
19 Sep 15:35:09 ntpd[23566]: synchronized to 91.207.136.50, stratum 2

20 Sep 14:42:57 ntpd[23566]: synchronized to 95.104.192.10, stratum 2
20 Sep 15:42:44 ntpd[23566]: time reset -0.203091 s
20 Sep 15:46:58 ntpd[23566]: synchronized to LOCAL(0), stratum 10
20 Sep 15:47:06 ntpd[23566]: synchronized to 93.180.6.3, stratum 2
20 Sep 15:52:21 ntpd[23566]: synchronized to 95.104.192.10, stratum 2
20 Sep 15:55:38 ntpd[23566]: synchronized to 91.207.136.50, stratum 2
20 Sep 16:06:05 ntpd[23566]: synchronized to 95.104.192.10, stratum 2
20 Sep 16:06:05 ntpd[23566]: time reset -0.350172 s
20 Sep 16:10:04 ntpd[23566]: synchronized to LOCAL(0), stratum 10
20 Sep 16:11:10 ntpd[23566]: synchronized to 91.207.136.50, stratum 2
20 Sep 16:32:39 ntpd[23566]: synchronized to 93.180.6.3, stratum 2
20 Sep 16:32:39 ntpd[23566]: time reset -0.445498 s
20 Sep 16:36:53 ntpd[23566]: synchronized to LOCAL(0), stratum 10
20 Sep 16:37:03 ntpd[23566]: synchronized to 93.180.6.3, stratum 2
20 Sep 16:41:10 ntpd[23566]: synchronized to 91.207.136.50, stratum 2
20 Sep 16:46:42 ntpd[23566]: synchronized to 95.104.192.10, stratum 2
20 Sep 16:50:41 ntpd[23566]: synchronized to 91.207.136.50, stratum 2
20 Sep 16:53:02 ntpd[23566]: synchronized to 95.104.192.10, stratum 2
20 Sep 16:54:57 ntpd[23566]: time reset -0.529673 s
20 Sep 16:58:36 ntpd[23566]: synchronized to LOCAL(0), stratum 10
20 Sep 16:59:42 ntpd[23566]: synchronized to 95.104.192.10, stratum 2
20 Sep 17:10:25 ntpd[23566]: synchronized to 91.207.136.50, stratum 2
20 Sep 17:14:55 ntpd[23566]: time reset -0.599156 s
20 Sep 17:18:17 ntpd[23566]: synchronized to LOCAL(0), stratum 10
20 Sep 17:20:27 ntpd[23566]: synchronized to 91.207.136.50, stratum 2
20 Sep 17:23:39 ntpd[23566]: synchronized to 95.104.192.10, stratum 2
20 Sep 17:24:42 ntpd[23566]: synchronized to 91.207.136.50, stratum 2
20 Sep 17:33:14 ntpd[23566]: synchronized to 95.104.192.10, stratum 2
20 Sep 17:40:56 ntpd[23566]: time reset -0.686162 s
20 Sep 17:45:07 ntpd[23566]: synchronized to LOCAL(0), stratum 10
20 Sep 17:46:11 ntpd[23566]: synchronized to 91.207.136.50, stratum 2
20 Sep 17:49:25 ntpd[23566]: synchronized to 93.180.6.3, stratum 2
20 Sep 17:59:44 ntpd[23566]: synchronized to 91.207.136.50, stratum 2
20 Sep 18:04:55 ntpd[23566]: synchronized to 93.180.6.3, stratum 2
20 Sep 18:04:54 ntpd[23566]: time reset -0.765875 s
20 Sep 18:09:06 ntpd[23566]: synchronized to LOCAL(0), stratum 10
20 Sep 18:10:11 ntpd[23566]: synchronized to 91.207.136.50, stratum 2
20 Sep 18:13:25 ntpd[23566]: synchronized to 95.104.192.10, stratum 2
20 Sep 18:29:10 ntpd[23566]: time reset -0.866628 s
20 Sep 18:32:43 ntpd[23566]: synchronized to LOCAL(0), stratum 10
20 Sep 18:34:52 ntpd[23566]: synchronized to 95.104.192.10, stratum 2
20 Sep 18:39:08 ntpd[23566]: synchronized to 91.207.136.50, stratum 2
20 Sep 18:48:46 ntpd[23566]: synchronized to 95.104.192.10, stratum 2
20 Sep 18:50:29 ntpd[23566]: synchronized to 91.207.136.50, stratum 2
20 Sep 18:53:05 ntpd[23566]: synchronized to 95.104.192.10, stratum 2
20 Sep 18:53:04 ntpd[23566]: time reset -0.947946 s
20 Sep 18:57:20 ntpd[23566]: synchronized to LOCAL(0), stratum 10
20 Sep 18:58:23 ntpd[23566]: synchronized to 95.104.192.10, stratum 2
20 Sep 19:03:45 ntpd[23566]: synchronized to 93.180.6.3, stratum 2
20 Sep 19:07:19 ntpd[23566]: synchronized to 91.207.136.50, stratum 2
20 Sep 19:12:26 ntpd[23566]: synchronized to 95.104.192.10, stratum 2
20 Sep 19:13:57 ntpd[23566]: time reset -1.029435 s
20 Sep 19:17:12 ntpd[23566]: synchronized to LOCAL(0), stratum 10
20 Sep 19:19:18 ntpd[23566]: synchronized to 95.104.192.10, stratum 2
20 Sep 19:27:57 ntpd[23566]: synchronized to 91.207.136.50, stratum 2
20 Sep 19:31:13 ntpd[23566]: synchronized to 95.104.192.10, stratum 2
20 Sep 19:39:45 ntpd[23566]: synchronized to 91.207.136.50, stratum 2
20 Sep 19:39:44 ntpd[23566]: time reset -1.115465 s
20 Sep 19:44:02 ntpd[23566]: synchronized to LOCAL(0), stratum 10
20 Sep 19:45:05 ntpd[23566]: synchronized to 93.180.6.3, stratum 2
20 Sep 19:45:17 ntpd[23566]: synchronized to 91.207.136.50, stratum 2
20 Sep 19:49:24 ntpd[23566]: synchronized to 95.104.192.10, stratum 2
20 Sep 19:51:33 ntpd[23566]: synchronized to 93.180.6.3, stratum 2
20 Sep 19:53:56 ntpd[23566]: synchronized to 95.104.192.10, stratum 2
20 Sep 20:02:16 ntpd[23566]: synchronized to 91.207.136.50, stratum 2
20 Sep 20:05:25 ntpd[23566]: synchronized to 95.104.192.10, stratum 2
20 Sep 20:05:24 ntpd[23566]: time reset -1.202517 s
20 Sep 20:09:06 ntpd[23566]: synchronized to LOCAL(0), stratum 10
20 Sep 20:13:23 ntpd[23566]: synchronized to 93.180.6.3, stratum 2
20 Sep 20:17:42 ntpd[23566]: synchronized to 91.207.136.50, stratum 2
20 Sep 20:25:13 ntpd[23566]: synchronized to 95.104.192.10, stratum 2
20 Sep 20:31:20 ntpd[23566]: synchronized to 91.207.136.50, stratum 2
20 Sep 20:33:06 ntpd[23566]: time reset -1.313646 s
20 Sep 20:36:33 ntpd[23566]: synchronized to LOCAL(0), stratum 10

| В виртуалке в которой ntpd запущен работает еще система биллинга, могло ли быть такое - что в момент появления диких рассинхронов времени (см лог) запущенный ntpd как бы замерзал внутри высоконагруженной виртуалки и по причине нехватки ресурсов CPU тормозил на 20 и более сек?

Может и могло. Я не запускал ntpd в OVZ-контейнере и даже мыслей таких не возникало, честно говоря. Плюс вопрос, как ведёт себя та штука в ядре, которая RTC синхронизирует, когда оно ещё и из контейнера это делать пытается (хотя пытается ли - это тоже вопрос открытый). В общем, не хочется и разбираться. У меня ntpd в хост-системе, синхронизируется с двух внешних ntp-серверов (моих же), а уже они синхронизируются по внешним наружу. Так что за безопасностью со стороны ntp у хостситемы особо смотреть не надо, соответственно и огород с виртуалкой под него городить.

| Плюс вопрос, как ведёт себя та штука в ядре, которая RTC синхронизирует, когда оно ещё и из контейнера это делать пытается (хотя пытается ли - это тоже вопрос открытый).

Как мне кажется пытается и даже успешно, в соседней виртуалке dovecot то валился.