Oh espere. Fevereiro 10º? Não. ntp não irá sincronizar tão longe. É por segundos e milissegundos; não horas e dias.
Você deve definir a data aproximadamente com date ou com precisão com ntpdate primeiro.
Eu configurei um servidor NTP em uma máquina em outra sub-rede e tentei sincronizar minha máquina com o servidor e ele funciona bem. Mas quando eu tento usar os servidores pool.ntp.org (eu tentei 0.pool.ntp.org, 1.pool.ntp.org, etc. e apenas servidores pool.ntp.org), ele não sincroniza. / p>
O nslookup no pool.ntp.org, assim como o 0.pool.ntp.org, fornece resolução adequada de DNS e o ping funciona nos IPs retornados pelo nslookup também.
A saída de iptables para o UDP é a seguinte:
[qui 10 fev 12:39:14 root @ root-ubuntu: ~] # iptables -L -n -v | grep udp
92 13001 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 state RELATED,ESTABLISHED
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:123
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:161
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:443
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:623
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:389
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:636
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:3268
0 0 ACCEPT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:3269
A saída do comando netstat é a seguinte:
[qui 10 fev 12:35:51 root @ root-ubuntu: ~] # netstat -a | grep udp
udp 0 0 localhost:9473 0.0.0.0:*
udp 0 0 0.0.0.0:asf-rmcp 0.0.0.0:*
udp 0 0 173.39.22.123:ntp 0.0.0.0:*
udp 0 0 localhost:ntp 0.0.0.0:*
udp 0 0 0.0.0.0:ntp 0.0.0.0:*
udp 0 0 all-systems.mcast.net:23000 0.0.0.0:*
udp 0 0 ::1:ntp ::%628620:*
udp 0 0 fe80::222:bdff:feea:9f1f:ntp ::%628620:*
udp 0 0 fe80::222:bdff:feea:9f20:ntp ::%628620:*
udp 0 0 :::ntp ::%628620:*
Não consigo descobrir por que o problema de sincronização está acontecendo apenas com os servidores do pool e não com o servidor local. As portas UDP no meu sistema estão funcionando. Os servidores estão funcionando. Tempo, no entanto, não sincroniza (Ainda está exibindo 10 de fevereiro.)
[EDITAR] Adicionando meu arquivo .conf:
driftfile /tmp/ntp.drift/
server 0.pool.ntp.org
Adicionando ntpq -p data:
[Qui Feb 10 14:13:51 root @ root-ubuntu: ~] # ntpq -p 0.pool.ntp.org
remote refid st t when poll reach delay offset jitter
==============================================================================
*64.147.116.229 .ACTS. 1 u 151 1024 377 2.439 -0.632 0.052
+131.107.13.100 .ACTS. 1 u 879 1024 377 27.853 1.041 0.539
-time.nrc.ca 132.246.11.231 2 u 989 1024 377 86.821 -4.132 8.778
-time1.chu.nrc.c 209.87.233.52 2 u 53 1024 377 109.221 3.153 9.377
+dense.utcc.utor 128.100.200.166 2 u 88 1024 377 64.115 -1.841 0.454
-dns4.utoronto.c 128.100.103.253 2 u 167 1024 377 65.252 -43.422 56.093
Oh espere. Fevereiro 10º? Não. ntp não irá sincronizar tão longe. É por segundos e milissegundos; não horas e dias.
Você deve definir a data aproximadamente com date ou com precisão com ntpdate primeiro.
Ele está ganhando tempo com o servidor NTP, mas não ajusta o tempo do sistema tão drasticamente automaticamente, porque isso pode causar sérios problemas. Portanto, você deve definir a data manualmente para a hora aproximada, de preferência dentro de um minuto, ou usar um programa alternativo para sincronizar a hora que o levará gradualmente a ser atualizado usando etapas de tempo incrementais.
Se você está com muitos dias ou meses desatualizado, deve resolver o motivo pelo qual isso está acontecendo, em vez de esperar que ele seja corrigido automaticamente. Imagine o que esse tipo de salto de tempo poderia estar fazendo com seus logs de servidor e bancos de dados, por exemplo - é por isso que os clientes NTP não irão sincronizar com essas diferenças drásticas.
Alternativas posso pensar em que ajustam sensivelmente o tempo em linha com um servidor são chrony e proxmox .