O OpenBSD 6.0 ntpctl diz “sincronizado com clock”, mas está ~ 26 segundos atras

Question

Meu host OpenBSD está executando o NTPD, mas demora 26 segundos, apesar de dizer "sincronizado com o relógio":

user@host:~# ntpctl -sa
4/4 peers valid, clock synced, stratum 3

peer
   wt tl st  next  poll          offset       delay      jitter
216.239.35.0 time1.google.com
    1 10  2 1063s 1078s        -1.951ms   101.103ms     0.594ms
216.239.35.4 time2.google.com
 *  1 10  2  481s 1067s        -1.742ms   112.251ms     0.447ms
216.239.35.8 time3.google.com
    1 10  2  729s  991s        -1.472ms    11.454ms     0.169ms
216.239.35.12 time4.google.com
    1 10  2  830s 1051s        -2.203ms   268.285ms     8.564ms

/etc/ntpd.conf contents:

server time1.google.com
server time2.google.com
server time3.google.com
server time4.google.com

/etc/rc.conf.local contents:

nsd_flags=
ntpd_flags=-s
unbound_flags=
dhcpd_flags=vmx0

uname -a output:

OpenBSD host.domain.xxx 6.0 GENERIC.MP#2319 amd64

Estou usando os servidores de horário do Google recentemente introduzidos . Eu tenho várias máquinas Debian ( Linux hostname 3.16.0-4-amd64 #1 SMP Debian 3.16.36-1+deb8u2 (2016-10-19) x86_64 GNU/Linux ) que estão sincronizadas corretamente.

Depois de alterar /etc/ntpd.conf e /etc/rc.conf.local , reiniciei o NTPD e reiniciei. Ainda está por trás.

Eu tentei ntpd -s -d , o que dá:

user@host:~# ntpd -s -d
ntp engine ready
reply from 216.239.35.8: offset -0.002133 delay 0.011241, next query 9s
set local clock to Thu Dec  1 16:50:01 CET 2016 (offset -0.002133s)
reply from 216.239.35.0: offset -0.001434 delay 0.099329, next query 8s
reply from 216.239.35.4: offset -0.001749 delay 0.109564, next query 8s
reply from 216.239.35.12: offset -0.001908 delay 0.263908, next query 9s
reply from 216.239.35.0: offset -0.000319 delay 0.101452, next query 7s
reply from 216.239.35.4: offset -0.000641 delay 0.111670, next query 9s
reply from 216.239.35.8: offset 0.000052 delay 0.011303, next query 8s
reply from 216.239.35.12: offset -0.000872 delay 0.266129, next query 8s
reply from 216.239.35.0: offset -0.000597 delay 0.101577, next query 5s
reply from 216.239.35.8: offset -0.000018 delay 0.011269, next query 6s
reply from 216.239.35.4: offset -0.000755 delay 0.111866, next query 5s
reply from 216.239.35.12: offset -0.000842 delay 0.265926, next query 6s
peer 216.239.35.0 now valid
reply from 216.239.35.0: offset -0.000587 delay 0.101456, next query 5s
peer 216.239.35.4 now valid
reply from 216.239.35.4: offset -0.005059 delay 0.120511, next query 6s
peer 216.239.35.8 now valid
reply from 216.239.35.8: offset 0.000012 delay 0.011377, next query 9s
peer 216.239.35.12 now valid
reply from 216.239.35.12: offset -0.000859 delay 0.266074, next query 8s
reply from 216.239.35.0: offset -0.000591 delay 0.101480, next query 5s
reply from 216.239.35.4: offset -0.000681 delay 0.111761, next query 8s
reply from 216.239.35.0: offset -0.000675 delay 0.101565, next query 6s
reply from 216.239.35.12: offset -0.000896 delay 0.266249, next query 9s
reply from 216.239.35.8: offset -0.000090 delay 0.011496, next query 6s
reply from 216.239.35.0: offset -0.000676 delay 0.101632, next query 33s
reply from 216.239.35.4: offset -0.000636 delay 0.111738, next query 7s
reply from 216.239.35.8: offset 0.000037 delay 0.011290, next query 9s
reply from 216.239.35.12: offset -0.000871 delay 0.266122, next query 8s
reply from 216.239.35.4: offset -0.000649 delay 0.111825, next query 31s
reply from 216.239.35.8: offset 0.000018 delay 0.011296, next query 32s
reply from 216.239.35.12: offset -0.000922 delay 0.266301, next query 30s
reply from 216.239.35.0: offset -0.000634 delay 0.101520, next query 32s
reply from 216.239.35.4: offset -0.000732 delay 0.111862, next query 30s
reply from 216.239.35.8: offset 0.000041 delay 0.011358, next query 32s
reply from 216.239.35.12: offset -0.000903 delay 0.266024, next query 31s
reply from 216.239.35.0: offset 0.001242 delay 0.101406, next query 34s
reply from 216.239.35.4: offset -0.000638 delay 0.115180, next query 33s
reply from 216.239.35.12: offset 0.000838 delay 0.266193, next query 34s
reply from 216.239.35.8: offset 0.001788 delay 0.011284, next query 34s
clock is now synced
reply from 216.239.35.0: offset -0.000130 delay 0.101597, next query 33s
reply from 216.239.35.4: offset -0.000103 delay 0.111680, next query 34s
reply from 216.239.35.8: offset 0.000554 delay 0.011275, next query 30s
reply from 216.239.35.12: offset -0.000391 delay 0.266116, next query 33s
reply from 216.239.35.0: offset -0.000070 delay 0.101481, next query 32s
reply from 216.239.35.4: offset -0.000163 delay 0.111739, next query 33s
reply from 216.239.35.8: offset 0.000451 delay 0.011480, next query 31s
reply from 216.239.35.12: offset -0.000396 delay 0.266210, next query 30s
^Cntp engine exiting
Terminating

O mesmo aqui, algumas linhas acima da parte inferior, dizem que "o relógio está agora sincronizado", mas ainda está por trás de ~ 26 segundos. Já faz mais de um dia e está tão fora quanto ontem, então não parece estar corrigindo devagar (ou está corrigindo muito devagar).

edit: como apontado por Rui F Ribeiro ; Esqueci de mencionar que a máquina é uma VM (guest) em execução em um host ESXi 6. As máquinas / convidados do Debian mencionados acima estão, no entanto, no mesmo host. Minha lógica era que, como eles parecem funcionar bem, o OpenBSD não deveria ser diferente?

O que eu posso fazer / tentar fazer meu OpenBSD sincronizar corretamente?

edit: conforme solicitado por Bink (eventos ntpd de) /var/log/daemon de conteúdo:

Nov 21 00:06:05 <hostname> ntpd[7477]: adjusting clock frequency by 0.317142 to -14.304083ppm
Nov 22 02:29:01 <hostname> ntpd[7477]: adjusting clock frequency by 0.305442 to -13.998538ppm
Nov 22 15:27:20 <hostname> ntpd[7477]: adjusting clock frequency by -0.138739 to -14.137278ppm
Nov 23 07:42:51 <hostname> ntpd[7477]: adjusting clock frequency by -0.061709 to -14.198986ppm
Nov 23 15:37:42 <hostname> ntpd[7477]: adjusting clock frequency by -0.303711 to -14.502698ppm
Nov 24 01:57:52 <hostname> ntpd[7477]: adjusting clock frequency by 0.266837 to -14.235861ppm
Nov 24 15:28:31 <hostname> ntpd[7477]: adjusting clock frequency by -0.223563 to -14.459424ppm
Nov 25 05:13:04 <hostname> ntpd[7477]: adjusting clock frequency by -0.223494 to -14.682917ppm
Nov 25 18:10:03 <hostname> ntpd[7477]: adjusting clock frequency by -0.324446 to -15.007363ppm
Nov 26 08:20:06 <hostname> ntpd[7477]: adjusting clock frequency by 0.295603 to -14.711760ppm
Nov 26 20:49:23 <hostname> ntpd[7477]: adjusting clock frequency by 0.517934 to -14.193826ppm
Nov 27 07:56:01 <hostname> ntpd[7477]: adjusting clock frequency by -0.269159 to -14.462985ppm
Nov 27 21:58:31 <hostname> ntpd[7477]: adjusting clock frequency by 0.239882 to -14.223103ppm
Nov 28 07:36:25 <hostname> ntpd[7477]: adjusting clock frequency by -0.435059 to -14.658162ppm
Nov 28 16:34:59 <hostname> ntpd[7477]: adjusting clock frequency by -0.299615 to -14.957777ppm
Nov 29 09:26:36 <hostname> ntpd[7477]: adjusting clock frequency by 0.137505 to -14.820272ppm
Nov 30 14:31:15 <hostname> ntpd[7477]: adjusting clock frequency by -0.215574 to -14.991138ppm
Nov 30 18:27:39 <hostname> ntpd[26935]: ntp engine exiting
Nov 30 18:27:39 <hostname> ntpd[3531]: dispatch_imsg in main: pipe closed
Nov 30 18:27:39 <hostname> ntpd[7477]: Terminating
Nov 30 18:27:55 <hostname> ntpd[27795]: ntp engine ready
Nov 30 18:27:58 <hostname> ntpd[27795]: ntp engine exiting
Nov 30 18:27:58 <hostname> ntpd[30737]: dispatch_imsg in main: pipe closed
Nov 30 18:27:58 <hostname> ntpd[15335]: Terminating
Nov 30 18:27:58 <hostname> ntpd[49555]: ntp engine ready
Nov 30 18:28:21 <hostname> ntpd[49555]: peer 216.239.35.0 now valid
Nov 30 18:28:22 <hostname> ntpd[49555]: peer 216.239.35.4 now valid
Nov 30 18:28:23 <hostname> ntpd[49555]: peer 216.239.35.12 now valid
Nov 30 18:28:24 <hostname> ntpd[49555]: peer 216.239.35.8 now valid
Nov 30 18:30:25 <hostname> ntpd[49555]: clock is now synced
Nov 30 18:40:47 <hostname> ntpd[10865]: ntp engine ready
Nov 30 18:40:47 <hostname> ntpd[36747]: set local clock to Wed Nov 30 18:40:47 CET 2016 (offset 0.000113s)
Nov 30 18:41:07 <hostname> ntpd[10865]: peer 216.239.35.8 now valid
Nov 30 18:41:07 <hostname> ntpd[10865]: peer 216.239.35.4 now valid
Nov 30 18:41:08 <hostname> ntpd[10865]: peer 216.239.35.12 now valid
Nov 30 18:41:09 <hostname> ntpd[10865]: peer 216.239.35.0 now valid
Nov 30 18:44:08 <hostname> ntpd[10865]: clock is now synced
Nov 30 18:48:10 <hostname> ntpd[49555]: ntp engine exiting
Nov 30 18:48:10 <hostname> ntpd[44908]: dispatch_imsg in main: pipe closed
Nov 30 18:48:10 <hostname> ntpd[59920]: Terminating
Nov 30 18:48:10 <hostname> ntpd[57325]: ntp engine ready
Nov 30 18:48:11 <hostname> ntpd[4035]: set local clock to Wed Nov 30 18:48:11 CET 2016 (offset 0.000388s)
Nov 30 18:48:29 <hostname> ntpd[57325]: peer 216.239.35.8 now valid
Nov 30 18:48:32 <hostname> ntpd[57325]: peer 216.239.35.4 now valid
Nov 30 18:48:32 <hostname> ntpd[57325]: peer 216.239.35.0 now valid
Nov 30 18:48:33 <hostname> ntpd[57325]: peer 216.239.35.12 now valid
Nov 30 18:50:57 <hostname> ntpd[53395]: Terminating
Nov 30 18:50:57 <hostname> ntpd[57325]: ntp engine exiting
Nov 30 18:50:57 <hostname> ntpd[26288]: dispatch_imsg in main: pipe closed
Nov 30 18:50:57 <hostname> ntpd[50972]: ntp engine ready
Nov 30 18:50:57 <hostname> ntpd[71389]: set local clock to Wed Nov 30 18:50:57 CET 2016 (offset 0.000046s)
Nov 30 18:51:14 <hostname> ntpd[50972]: peer 216.239.35.0 now valid
Nov 30 18:51:19 <hostname> ntpd[50972]: peer 216.239.35.4 now valid
Nov 30 18:51:21 <hostname> ntpd[50972]: peer 216.239.35.12 now valid
Nov 30 18:51:23 <hostname> ntpd[50972]: peer 216.239.35.8 now valid
Nov 30 18:53:46 <hostname> ntpd[46409]: ntp engine ready
Nov 30 18:53:47 <hostname> ntpd[51869]: set local clock to Wed Nov 30 18:53:47 CET 2016 (offset 0.017304s)
Nov 30 18:54:05 <hostname> ntpd[46409]: peer 216.239.35.0 now valid
Nov 30 18:54:06 <hostname> ntpd[46409]: peer 216.239.35.4 now valid
Nov 30 18:54:08 <hostname> ntpd[46409]: peer 216.239.35.8 now valid
Nov 30 18:54:08 <hostname> ntpd[46409]: peer 216.239.35.12 now valid
Nov 30 18:57:13 <hostname> ntpd[46409]: clock is now synced
Nov 30 19:15:19 <hostname> ntpd[43240]: adjusting clock frequency by 0.420934 to -14.570066ppm
Nov 30 19:34:26 <hostname> ntpd[43240]: adjusting clock frequency by 0.080845 to -14.489222ppm
Nov 30 19:53:41 <hostname> ntpd[43240]: adjusting clock frequency by -0.092990 to -14.582212ppm
Dec  1 16:56:15 <hostname> ntpd[43240]: Terminating
Dec  1 16:56:15 <hostname> ntpd[46409]: ntp engine exiting
Dec  1 16:56:15 <hostname> ntpd[59696]: dispatch_imsg in main: pipe closed
Dec  1 16:56:15 <hostname> ntpd[61779]: ntp engine ready
Dec  1 16:56:15 <hostname> ntpd[64211]: set local clock to Thu Dec  1 16:56:15 CET 2016 (offset 0.000150s)
Dec  1 16:56:16 <hostname> ntpd[61779]: ntp engine exiting
Dec  1 16:56:16 <hostname> ntpd[76241]: Terminating
Dec  1 16:56:16 <hostname> ntpd[48763]: dispatch_imsg in main: pipe closed
Dec  1 16:56:16 <hostname> ntpd[19408]: ntp engine ready
Dec  1 16:56:16 <hostname> ntpd[89788]: set local clock to Thu Dec  1 16:56:16 CET 2016 (offset 0.000336s)
Dec  1 16:56:35 <hostname> ntpd[19408]: peer 216.239.35.8 now valid
Dec  1 16:56:36 <hostname> ntpd[19408]: peer 216.239.35.12 now valid
Dec  1 16:56:38 <hostname> ntpd[19408]: peer 216.239.35.4 now valid
Dec  1 16:56:38 <hostname> ntpd[19408]: peer 216.239.35.0 now valid
Dec  1 17:00:49 <hostname> ntpd[19408]: clock is now synced
Dec  1 17:22:51 <hostname> ntpd[68037]: adjusting clock frequency by -0.076636 to -14.641308ppm

O início / fim, etc., é o meu teste / teste de coisas.

    

Answer 1

O OpenBSD e sua VM estão funcionando direito; você está usando mal a fonte de horário do Google.

Isso está nas Perguntas frequentes do OpenBSD e nas páginas de manual.

Você está sincronizando com uma fonte de horário que publica a hora UTC, mais ou menos. Mas por padrão, rdate assume que sua fonte de tempo publica o tempo TAI-10. O TAI, uma contagem estritamente crescente de todos os segundos de SI com sempre 60 segundos por minuto, está atualmente 36 segundos à frente do UTC, que ocasionalmente desconta os chamados "segundos bissextos". (Mais precisamente: ele desconta positivo segundos bissextos; mas ainda não houve um segundo bissexto negativo.) Serão 37 segundos à frente da UTC em 2016-12-31 23:59:60 UTC, o segundo bissexto chegando no final deste mês.

Sistemas que usam TAI, em vez de UTC, na verdade, tendem a usar o que é mais precisamente conhecido como TAI-10, que é a contagem de TAI transferida para o futuro em 10, de modo que se alinhe 1970-01-01 00:00:00 UTC , também conhecido como 1969-12-31 23:59:50 TAI, com 1970-01-01 00:00:00 TAI-10. ¹ Isso é 26 segundos à frente da UTC, que em breve se tornará 27.

Felizmente, as fontes de tempo do Google não contam como segundos bissextos. Eles usam o smearing que espalha o valor do segundo extra não contado ao longo de um dia inteiro, o que significa que por até dois dias por ano os segundos do Google não têm comprimento uniforme não têm o mesmo comprimento que um segundo SI.

rdate precisa da opção -c para informar que sua fonte de tempo não conta em segundos, e você precisa usar um fuso horário "certo" Olsen que assume que o clock do seu kernel é executado no TAI-10. (timezones "certos" e um relógio do kernel que conta o TAI ao invés do UTC tem suas vantagens.)

Ironicamente, como você também está usando o Tempo da Europa Central de acordo com seus registros, as configurações de exemplo dadas nas Perguntas Freqüentes do OpenBSD são exatamente as que são para você. . Então leia o documento do OpenBSD e siga as instruções.

Ou: Se você quer rodar em UTC ao invés de TAI-10, use os fusos horários "posix".

^{1 Esta é uma explicação ligeiramente simplificada que envolve uma definição retroativa comumente usada de UTC, e ignora o fato de que os segundos UT usados antes de 1972 eram de comprimento variável com algoritmos grandes baseados em tabelas para converter de / para TAI . Mas isso está além do escopo desta resposta. A situação anterior a 1972 era horrenda. Algumas pessoas querem acabar com o UTC e seu segundo sistema de salto e o segundo comprimento do SI, e trazê-lo de volta. Eles são ... equivocados.}

Leitura adicional

• " Por que meu relógio está desligado por vinte segundos? ". Perguntas Frequentes do OpenBSD .
• rdate . Manual do OpenBSD 6.0.
• Christopher Pascoe (2011-09-15). Tempo, tecnologia e segundos saltando . Google.
• Perry Lorier (2015-07-01). time X .google.com fornecem tempo não padrão . # 437 rastreador de bugs do systemd.
• Daniel J. Bernstein. horário UTC, TAI e UNIX . cr.yp.to.
• David Madore (2010-12-27). " A configuração do TAI-10 ". A segunda bagunça do Unix .
• link

Answer 2

26 é um número mágico, é (hoje) o número de segundos adicionados à UTC.

Você está comparando a hora do OpenBSD com um sistema Debian que tem os arquivos "right" zoneinfo?

TZ=/usr/share/zoneinfo/right/GB-Eire date; date
Thu Dec  1 19:46:16 GMT 2016
Thu Dec  1 19:46:41 GMT 2016

(desculpas, estou com apenas 25 segundos de atraso, pois não atualizei minhas tzdata para contabilizar o ano passado pulo)

As origens desta mentira em interpretações estritas de POSIX, das quais você pode ler mais aqui:   link

    

Answer 3

Apesar de já ter executado o OpenBSD no VMware, se o host da VM tiver o horário correto, você pode tentar usar o driver VMware Tools integrado do OpenBSD, vmt (4), como um sensor para ntpd (8 ) em vez dos servidores de tempo. Se isso não funcionar, você pode tentar, adicionalmente, definir kern.timecounter.hardware = acpitimer0 via sysctl (8).

Postar a saída do ntpd em / var / log / daemon também pode ser útil.