Em nossa caixa de produção, estou enfrentando um problema com o ntpd. Estou habilitando o recurso NTP para nossa caixa de produção e observando um problema.
Iniciamos o daemon ntpd no processo de inicialização de nossa caixa. Durante esse período, a conexão com a Internet não existe. Abaixo está meu pequeno ntp.confarquivo
driftfile /etc/ntp.drift
logconfig =syncstatus
server pool.ntp.org iburst
Nossa caixa obtém conectividade com a Internet um pouco tarde quando a interface é ativada. Dessa vez vejo que o ntpd não sincroniza o relógio. Quando eu faço isso ntpq -c as, eu entendo no association id's found. Esperei quase 30 minutos, mas ainda conseguino association id's found
Eu tenho que reiniciar o ntpd. Após reiniciá-lo, o ntpd sincroniza o relógio e tudo funciona normalmente. Mas, novamente, se eu reiniciar minha caixa, o mesmo problema acontecerá. Novamente eu tenho que reiniciar o ntpd, assim que a caixa aparecer e a internet estiver acessível.
Alguém enfrentou tipo de problema semelhante?
Devo atrasar o início do ntpd até que a interface de tempo apareça?
Atualizar
Fiz mais algumas experiências e substituí server pool.ntp.org iburstpor pool pool.ntp.org iburstesta alteração o ntpd sincroniza o relógio automaticamente. Não precisei reiniciar o ntpd. Então aqui surge outra questão para mim.
O que aconteceu quando substituí serverpor pool?
Devo sempre usar poolpalavras-chave em vez de server?
Quando devo usar poole quando devo usar server?
Eu fiz algumas pesquisas e descobri que
pool is the same as server, except it resolves one name into several addresses and uses them all
se eles estão fazendo a mesma coisa, então por que server pool.ntp.org iburstnão funcionou para mim, mas pool pool.ntp.org iburstfuncionou.
Atualizar
Como sugerido, usei poolem vez disso, servermas ainda assim meu relógio não consegue sincronizar na inicialização. Anteriormente no association id's foundestava chegando, mas depois de usar o pool ele está exibindo a lista.
GW:/admin# ntpq -c lpeer
remote refid st t when poll reach delay offset jitter
===================================================================== =========
time.google.com .POOL. 16 p - 64 0 0.000 +0.000 0.002
GW:/admin# ntpq -np
remote refid st t when poll reach delay offset jitter
time.google.com .POOL. 16 p - 64 0 0.000 +0.000 0.002
GW:/admin# ntpq -c as
ind assid status conf reach auth condition last_event cnt
===========================================================
1 34173 8811 yes none none reject mobilize 1
GW:/admin# ntpq -c "rv 34173"
associd=34173 status=8811 conf, bcast, sel_reject, 1 event, mobilize,
srcadr=0.0.0.0, srcport=0, srchost="time.google.com", dstadr=0.0.0.0,
dstport=0, leap=11, stratum=16, precision=-19, rootdelay=0.000,
rootdisp=0.000, refid=POOL, reftime=(no time), rec=(no time), reach=000,
unreach=0, hmode=3, pmode=0, hpoll=6, ppoll=10, headway=0,
flash=1400 peer_dist, peer_unreach, keyid=0, offset=+0.000, delay=0.000,
dispersion=16000.000, jitter=0.002,
filtdelay= 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00,
filtoffset= +0.00 +0.00 +0.00 +0.00 +0.00 +0.00 +0.00 +0.00,
filtdisp= 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0 16000.0
Vejo o status do flash como 1400. Qual é o significado de 1400não consegui encontrar o status do flash 1400na documentação do NTP.
Atualizar
Começou a funcionar. Substituí iburstpor minpoll 3 maxpoll 4e depois disso está funcionando na reinicialização. Eu usei piscina assim pool pool.ntp.org minpoll 3 maxpoll 4. Não tenho certeza de que diferença essa mudança fez.
Também li que devemos evitar usar minpoll e maxpoll.
Too frequent for a sustained period and public NTP services may block you. ntpd is already good at dynamically selecting the pool interval.
De qualquer forma obrigado a todos por me ajudarem.
Responder1
Quando você fornece um servidor para o ntpd, na inicialização ele resolve o nome do host para um endereço IP e tenta usar o endereço IP para sincronizar a hora. Se esse nome de host não for resolvido, ele será excluído. Mesmo que resolva, ele não lembra o nome do host, apenas o endereço IP.
Se o servidor na sua serverlinha fosse um host local com um endereço IP fixo (em vez de um pool dinâmico), você poderia substituir o nome do host pelo endereço IP real e não deveria excluí-lo, mesmo que a rede não estivesse ativa. comece.
Se você fornecer um pool para o ntpd, ele manterá o nome do host (e o marcará com .POOL.). Periodicamente (inclusive na inicialização), ele resolverá esse nome de host no DNS e adicionará quaisquer IPs obtidos como entradas separadas e removerá alguns dos menos favoráveis.
Você pode ver um pouco disso com o comando ntpq -np ou equivalententpq -n -c peers
Observe que também há problemas de tempo e de versão NTPD com tudo isso. Esse problema exato foi registrado como um bug no ntpd e houve diversas variações de correção. Algumas versões do ntpd adiarão a resolução do nome do host se falhar, mas poderão eventualmente desistir de qualquer maneira; portanto, se você estiver testando desconectando brevemente a rede e reconectando-a, o problema pode não ocorrer. Além disso, o ntp usa um algoritmo de pesquisa que aumenta exponencialmente o tempo de pesquisa do host para hosts alcançáveis e inacessíveis (dependendo da estabilidade do relógio e da utilidade do host como sincronização de tempo) com um limite superior de 1.024 segundos (32 minutos), portanto, se mudanças na acessibilidade da rede, pode levar muito tempo para que isso seja percebido. (Os horários e intervalos da pesquisa estão listados em ntpq -np)
Além disso, alguns scripts de inicialização usam ntpdate ou ferramentas semelhantes para definir o relógio do sistema para um servidor a partir do ntp.conf, para que o relógio seja parcialmente sincronizado antes do início do ntpd. Esta é uma tentativa única e, se falhar, o ntpd pode iniciar com o relógio totalmente errado. Se estiver apenas um pouco errado, o ntp irá corrigi-lo, mas se estiver muito errado, o ntpd pode se recusar a sincronizar o relógio e, em alguns casos e versões do ntpd, pode travar ou sair. Algumas versões do ntpd têm suas próprias opções de grande passo do relógio único.