Por que o ntpd não está atualizando o horário no meu servidor?

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 correr ntpdate -q ntp.ubuntu.com, me dizem que o relógio da minha máquina está desligado em 7 segundos.

O que está acontecendo? Como posso diagnosticar o que está acontecendo, existe um registro que eu possa ativar?

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

Aqui está o que parecia 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 o que o 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 uma saída como esta:

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 indica claramente que não sou capaz de definir o horário no meu servidor (embora, com o NTP normal, ele pareça atualizar algumas vezes ...).

mais informações # 4

Meu provedor VPS diz:

Os kernels mais recentes não devem travar seu sistema no relógio do dom0; para garantir, você pode definir xen.independent_wallclock = 1 no sysctl.conf.

Suponho que ainda não resolva o problema do VPS que precisa de uma CPU disponível para fazer cálculos de tempo corretos.

Você pode habilitar o login no ntpd adicionando isso ao ntp.conf:

logfile /var/log/ntpd.log

Fonte: manual ntp

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

# 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 pode modificar o relógio do sistema - isso só pode ser feito na máquina host.

Tudo bem pessoal, desde que fiz essa pergunta, eu reinstalei o ntp com a configuração padrão do fornecedor (Ubuntu 10.0.4) e o deixei rodar por alguns dias. No momento da redação deste documento, ntpdate -q ntp.ubuntu.commostra que meu tempo é preciso dentro de 0,000216 segundos. Portanto, os problemas que eu estava tendo devem ter sido com minha configuração personalizada (onde eu estava tentando tornar impossível para hosts externos consultarem meu servidor, o que eu já estou fazendo com meu firewall, então não estou muito preocupado com isso). Aqui está o Ubuntu 10.0.4 ntp.conf em sua totalidade, com os 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 um ticket com meu provedor de VPS, pedindo uma recomendação detalhada sobre a melhor coisa a fazer. Eu os apontei para esse segmento, e alguma outra documentação indicando que talvez a alocação da CPU cause um problema de temporização. Aqui está o que eles disseram:

Os kernels mais recentes não devem travar seu sistema no relógio do dom0; para garantir, você pode definir xen.independent_wallclock = 1 no sysctl.conf. Isso garantirá que a instância do servidor não esteja seguindo o relógio no servidor host.

e:

Acho que você pode entender mal o grau exato em que esse problema afeta os clientes NTP em um ambiente virtualizado. Na minha experiência em um sistema virtualizado em um host Xen (como nossa configuração na Rackspace Cloud), a imprecisão herdada por não ter um relógio de sistema dedicado para processar as interrupções equivale a frações de segundo, mesmo em sistemas altamente carregados. Essa pequena imprecisão é gerenciada com facilidade pelo NTP, mesmo que esteja configurada apenas para atualizar o horário dos servidores uma vez por dia (ou até menos menos que isso).

Um de 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á tanto do host real em que está sendo executado quanto da ocupação geral do vhost.

Dependendo da virtualização usada, o vhost pode não receber um compartilhamento constante de interrupções em um determinado período de tempo. Isso fará com que o relógio corra mais rápido ou mais devagar do que realmente está acontecendo. Como o ntp está tentando medir as mudanças no pressuposto de que o seu relógio é uma taxa fixa mais rápida ou mais lenta que o resto do mundo, essa aceleração e desaceleração fornecerão ajustes ntp e provavelmente acabarão desistindo, com o resultado que ntp -npmostra os servidores de horário que o ntp considerou inadequado.

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

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

1. Você precisa permitir o acesso ao localhost para o ntpd iniciar corretamente e realmente fazer coisas

   restrict 127.0.0.1
   restrict ::1
   

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

3. Você não menciona o uso restrictpara abrir o acesso aos seus servidores. Isso é um problema. Tente blocos como o seguinte:

   # ntp.xs4all.nl
   server          194.109.22.18
   restrict        194.109.22.18
   

4. Você precisa de vários pares ou servidores para o ntpd, pois ele tenta usar a maioria das regras de votação para lidar com um ator ruim. Portanto, no mínimo 4, para ainda conseguir a maioria quando você perde um, de preferência 5.

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

   restrict default notrust nomodify
   

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

6. Se você não está fornecendo serviço de horário para outras pessoas, provavelmente não precisa da capacidade total do ntpd regular e deve considerar openntpd. Escrito pela equipe do OpenBSD, é uma implementação muito mais mínima, usando 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 fornecerá, mas é facilmente bom o suficiente para um servidor ou estação de trabalho comum.

• Se o ntpd não conseguir se conectar ao servidor remoto, você não verá um deslocamento para esse servidor.
• Se o ntpq fosse bloqueado pelo ntpd, você veria uma mensagem de erro clara do ntpq.
• Se algum outro serviço definir também o horário (como ferramentas vmware), você verá um deslocamento de salto para o servidor (execute ntpq -p a cada 70 segundos).

A reach 7saída in ntpq indicou que você deixou o ntpd rodar apenas por cerca de 4 minutos. 7 é 111 binário, o que significa que o servidor já foi atingido 3 vezes. O ntp alcança a cada 64 segundos ( pollvalor) e já espera 30 segundos ( whenvalor) desde o último contato.

O offset -0.136indicado, que o sistema já está sincronizado. Somente o ntpd ainda não marcou o servidor como fonte. Apenas dê mais tempo e uma pequena estrela aparecerá.

Então, na verdade o seu ntpd estava sincronizando. Mas o ntpd geralmente não sincroniza em um grande salto (como o ntpdate), mas tenta ajustar o tempo lentamente e garantir, ao longo de vários ciclos, que o tempo seja estável.

PS: Estou ciente de que a pergunta é muito antiga. Mas a questão é atemporal. E todas as outras respostas são apenas IMHO enganosas. O ntpd é recomendado pelo VMWare para manter o tempo sincronizado.

Eu encontrei meu sistema desligado e intrigado por que o relógio HW não estava sincronizado 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ê possui um servidor NTP sólido e se o relógio do sistema é confiável.

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

Tenha um bom dia!

se você estiver executando o vhost no vmware, verifique o seguinte artigo .. ele deve ajudá-lo http://www.vmware.com/files/pdf/Timekeeping-In-VirtualMachines.pdf

Hai ..

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

http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_: Ch24 : _The_NTP_Server

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

E verificar sua data / hora?

E verifique isso também, execute ntpdate e ntpd de inicialização. O tempo está sincronizado?

com os melhores desejos