Por que o ntpd não está atualizando a hora no meu servidor?

Question

Eu tenho o ntpd em execução no meu servidor. São todas as configurações padrão, exceto que eu comentei sua capacidade de ser um servidor para outras máquinas:

# restrict -4 default kod notrap nomodify nopeer noquery                                                                    
# restrict -6 default kod notrap nomodify nopeer noquery   
restrict default ignore

Se eu executar ntpdate -q ntp.ubuntu.com , sou informado de que o relógio da minha máquina está desativado em 7 segundos.

O que está acontecendo? Como posso diagnosticar o que está acontecendo, há um log que eu possa ligar?

mais informações # 1

# ntpq -np
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 91.189.94.4     193.79.237.14    2 u   30   64    7  108.518   -0.136   0.361

mais informações # 2

Veja como isso ficou quando fiz a pergunta:

# ntpdate -q ntp.ubuntu.com
server 91.189.94.4, stratum 2, offset 7.191308, delay 0.13310
10 Jan 20:38:09 ntpdate[31055]: step time server 91.189.94.4 offset 7.191308 sec

E aqui está o que parece agora, depois de reiniciar o ntpd algumas vezes (suponho que foi isso que corrigiu):

# ntpdate -q ntp.ubuntu.com
server 91.189.94.4, stratum 2, offset 0.000112, delay 0.13164
10 Jan 20:47:03 ntpdate[31419]: adjust time server 91.189.94.4 offset 0.000112 sec

mais informações # 3

Eu desinstalei o ntp e instalei o openntpd e executei /usr/sbin/ntpd -d , e estou vendo a saída assim:

reply from 64.73.32.134: offset 6.715003 delay 0.041152, next query 30s
reply from 208.53.158.34: offset 6.700224 delay 0.036263, next query 31s
adjusting local clock by 6.734120s
reply from 72.18.205.156: offset 6.708575 delay 0.035885, next query 30s
reply from 64.73.32.134: offset 6.701463 delay 0.044199, next query 33s

O que para mim claramente indica que não posso definir a hora no meu servidor (embora, com o ntp normal, pareça atualizar algumas vezes ...).

mais informações # 4

Meu provedor de VPS diz:

The latest kernels should not lock your system to our dom0's clock, to be on the safe side you can set xen.independent_wallclock = 1 in your sysctl.conf.

O que eu suponho ainda não resolve a questão do VPS que precisa de uma CPU disponível para fazer cálculos de tempo corretos.

    

Answer 1

Tudo bem, desde que fiz esta pergunta, eu reinstalei o ntp com a configuração padrão do fornecedor (Ubuntu 10.0.4) e deixei ele funcionar por alguns dias. No momento em que escrevo, ntpdate -q ntp.ubuntu.com mostra que meu tempo está correto dentro de 0,000216 segundos. Então, os problemas que eu estava tendo devem ter sido com minha configuração personalizada (onde eu estava tentando tornar impossível para hosts externos consultar meu servidor, o que eu já estou fazendo com meu firewall, então não estou muito preocupado). Aqui está o Ubuntu 10.0.4 ntp.conf na sua totalidade, com comentários removidos:

driftfile /var/lib/ntp/ntp.drift

statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable

server ntp.ubuntu.com

restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery

restrict 127.0.0.1
restrict ::1

Congratulo-me com o feedback sobre como essa configuração pode ser melhorada.

Também fiz uma passagem com meu provedor de VPS solicitando uma recomendação detalhada sobre a melhor coisa a fazer. Eu apontei para este tópico, e alguma outra documentação indicando que talvez a alocação da CPU causaria um problema de temporização. Aqui está o que eles disseram:

The latest kernels should not lock your system to our dom0's clock, to be on the safe side you can set xen.independent_wallclock = 1 in your sysctl.conf. This will make sure the server instance isn't following the clock on the host server.

e:

I think you may be mis-understanding the exact degree to which this issue affects NTP clients in a virtualized environment. In my experience on a virtualized system on a Xen host (such as our setup at Rackspace Cloud) the inaccuracy inherited by not having a dedicated system clock to process the interrupts amounts to fractions of a second, even on highly loaded systems. This slight inaccuracy is easily managed by NTP even if it is only set to update the servers time once per day (or even less frequent than that).

    

Answer 2

Você pode habilitar o logging no ntpd adicionando isto ao ntp.conf:

logfile /var/log/ntpd.log

Fonte: manual do ntp

Se você desativar o ntpd, poderá atualizar o relógio pela linha de comando? Se você executar o comando ntpdate e receber um erro assim:

# ntpdate ntp.ubuntu.com
10 Jan 23:47:57 ntpdate[26284]: Can't adjust the time of day: Operation not permitted

Isso significa que você provavelmente está em um VPS e, nesse caso, não é possível modificar o relógio do sistema - isso só pode ser feito na máquina host.

    

Answer 3

Um dos seus comentários diz que você está executando em um vhost. Nesse caso, você provavelmente não terá muito sucesso, porque o senso de tempo do seu vhost dependerá do host real em que está sendo executado e de quão ocupado o vhost está.

Dependendo da virtualização usada, o vhost pode não obter uma parcela estável de interrupções em um determinado período de tempo. Isso fará com que o relógio funcione mais rápido ou mais devagar do que realmente está acontecendo. Como o ntp está tentando medir as mudanças na suposição de que o seu clock é fixo ou mais rápido que o resto do mundo, esta aceleração e desaceleração darão ntp fits e provavelmente acabará desistindo, com o resultado que ntp -np mostra os servidores de horário que o ntp considerou inadequados.

Sua melhor aposta se este for o caso é provavelmente uma força bruta rdate -s $server de vez em quando (como a cada seis horas) para arrancar o relógio pelo nariz para que ele não fique excessivamente fora de sincronia. Mas precisão minuciosa provavelmente está fora de alcance.

    

Answer 4

Coisas que encontrei no passado, quando usei o ntpd em vez do openntpd:

1. Você precisa permitir o acesso ao localhost para que o ntpd seja iniciado corretamente e realmente faça as coisas

   restrict 127.0.0.1
   restrict ::1
   

2. Embora você possa usar nomes de host para regras de servidor, abrir lacunas para falar com esses servidores significa usar restrict , que requer endereços IP, então acabei tendo que usar IPs para tudo de qualquer maneira.

3. Você não menciona usar restrict para abrir o acesso aos seus servidores. Isso é um problema. Tente blocos como os seguintes:

   # ntp.xs4all.nl
   server          194.109.22.18
   restrict        194.109.22.18
   

4. Você precisa de vários colegas ou servidores para o ntpd, já que ele tenta usar a votação de regras da maioria para lidar com um ator ruim. Então, um mínimo de 4, para ainda poder ter uma maioria quando você perde um, de preferência 5.

5. Para bloquear o acesso padrão, eu poderia usar:

   restrict default notrust nomodify
   

   para ainda poder consultar, mas acabei usando restrict default ignore como você faz quando o ntpd 4.2 mudou o significado de notrust . suspiro

6. Se você não está fornecendo serviço de tempo para os outros, provavelmente não precisa do poder total do ntpd regular e deve considerar openntpd . Escrito pela equipe do OpenBSD, é uma implementação muito mais minimalista, usando a separação de privilégios e um arquivo de configuração muito mais simples. Ele supostamente não fornecerá o tempo altamente preciso que o ntpd irá, mas é facilmente bom o suficiente para um servidor ou estação de trabalho regular.

Answer 5

se você estiver executando o vhost no vmware, verifique o seguinte artigo ... ele deve ajudá-lo link

    

Answer 6

Hai ..

Dê uma olhada nesta referência para ver se ela pode ajudar na solução do seu problema:

link Ch24 : _ O_NTP_Server

você pode querer postar o conteúdo do seu arquivo ntpd.conf, a saída dos comandos debug como ntpq -p

E verifique sua data / horário?

E verifique isso também, execute ntpdate e startup ntpd, o tempo está sendo mantido em sincronia?

com os melhores desejos

    

Answer 7

Descobri meu sistema e confuso por que o relógio HW não estava sincronizando com o relógio do sistema em um desligamento limpo. Parece que há uma configuração NTP no sysconfig que precisa ser editada para que isso aconteça.

Em /etc/sysconfig/ntpd :

# Set to 'yes' to sync hw clock after successful ntpdate
SYNC_HWCLOCK=no

Eu configurei isso para yes . É claro que primeiro verifique se você tem um servidor NTP sólido e se o relógio do seu sistema é confiável.

Eu sabia que era isso - minha inclinação era de 47 segundos e meu relógio HW também estava com 47 segundos de folga. Bingo! Minha primeira pista foram falhas de Kerberos vistas nos logs. O Kerberos e muitos NAS simplesmente não funcionarão se o desvio do clock for grande demais.

Tenha um bom dia!