Chrony time synchronization on huge time diff

hello currently i have a localy ntp server (chrony) and a ntp client (chrony), all are working but when i try to change ntp server time to say minus 6 years from current time. ntp client cannot sync with it, it will just say on syslog:

Jan 9 17:29:11 localhost chronyd[9192]: System clock wrong by 6780812.328260 seconds, adjustment started

ntp client (chrony) /etc/chrony.conf is on default configuration except that server is pointed to my local NTP server (chrony). Here is my config

# Use public servers from the pool.ntp.org project.
# Please consider joining the pool (http://www.pool.ntp.org/join.html).
#server 0.centos.pool.ntp.org iburst
#server 1.centos.pool.ntp.org iburst
#server 2.centos.pool.ntp.org iburst
#server 3.centos.pool.ntp.org iburst
server local.ntp.server iburst

# Ignore stratum in source selection.
stratumweight 0

# Record the rate at which the system clock gains/losses time.
driftfile /var/lib/chrony/drift

# Enable kernel RTC synchronization.
rtcsync

# In first three updates step the system clock instead of slew
# if the adjustment is larger than 10 seconds.
makestep 10 3

# Allow NTP client access from local network.
#allow 192.168/16

# Listen for commands only on localhost.
bindcmdaddress 127.0.0.1
bindcmdaddress ::1

# Serve time even if not synchronized to any NTP server.
#local stratum 10

keyfile /etc/chrony.keys

# Specify the key used as password for chronyc.
commandkey 1

# Generate command key if missing.
generatecommandkey

# Disable logging of client accesses.
noclientlog

# Send a message to syslog if a clock adjustment is larger than 0.5 seconds.
logchange 0.5

logdir /var/log/chrony
#log measurements statistics tracking

I do not know it wont sync, i've read that it will take longer time, but i've let my machine sit for 1 day and still ntp client didn't not have the same time as the ntp server (not synchronized). Any ideas? am tryin not to restart the chronyd service and just let it auto-sync the time

Note that "local.ntp.server" is define on my /etc/hosts. Also, NTP server and NTP client are not using ntpd service but it is using chronyd. And this kind of setup is an isolated one

3
задан 8 December 2016 в 11:25
3 ответа

Похоже, ваша проблема в том, что вы пытаетесь изменить время на шесть лет , сдвигая часы и отказываясь после ] one day .

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

Я считаю, что запускать лживые серверы NTP - очень плохая идея, но если вы настаиваете на этом , и вы внезапно перекосите сервер на любую значительную величину, вам нужно будет принудительно изменить часы клиента, прежде чем они смогут синхронизироваться. Это проще всего сделать, убедившись, что клиенты принудительно сбрасывают свои часы с сервера во время загрузки (с ntpd , это делается с помощью ntpdate во время загрузки; я не знаю о хронах) и перезагрузке клиентов.

4
ответ дан 3 December 2019 в 05:23

Если у вас слишком мало времени (дни или даже месяцы), синхронизация времени не будет работать (" это займет много времени "), потому что клиенты NTP, такие как Chrony, постепенно регулируют часы, замедляя или ускоряя их .

Добавьте эту строку в конфигурацию Chrony (например, / etc / chrony. conf или /etc/chrony/chrony.conf ):

makestep 1 -1

Затем перезапустите Chrony.

# systemctl restart chronyd
# or
# /etc/init.d/chrony restart

Объяснение:

Директива maketep может использоваться, чтобы позволить chronyd сдвигать часы. Например, если chrony.conf имеет

maketep 1 3

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

maketep 1–1

https://chrony.tuxfamily.org/faq.html#_is_code_chronyd_code_allowed_to_step_the_system_clock

2
ответ дан 3 December 2019 в 05:23

Если разница во времени огромна , то может не принять ваш источник. Мои часы были несколько лет назад и хроник отслеживания сообщал:

> chronyc tracking
Ref time (UTC) : Thu Jan 01 00:00:00 1970

Что сработало со мной, так это добавить максимальную разницу 1000000000 в /etc/chrony.conf, а затем (после хронический перезапуск) сделать chrnoyc - a maketep 1000 -1 .

.
0
ответ дан 3 December 2019 в 05:23

Теги

Похожие вопросы