Então, estou tentando depurar minha configuração atual do NTP e descobri que o deslocamento do meu único servidor configurado é superior a 3 segundos e não se ajusta. O asterisco no LOCAL (0) na saída ntpq parece indicar que o sistema está felizmente sincronizando consigo mesmo em vez do servidor 10.130.33.201 (que é outra caixa linux em nosso sistema que queremos que tudo seja sincronizado).
ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
10.130.33.201 LOCAL(0) 9 u 49 64 377 0.242 -3742.2 1.049
*LOCAL(0) .LOCL. 10 l 2 64 377 0.000 0.000 0.001
E este é o meu arquivo ntp.conf. Escrito por outra pessoa, então não tenho 100% de certeza de que tudo está correto.
server 10.130.33.201 burst iburst minpoll 4 maxpoll 11
driftfile /mnt/active/etc/ntp.drift
restrict -4 default nomodify nopeer notrap
restrict -6 default ignore
# Undisciplined Local Clock. This is a fake driver intended for backup
# and when no outside source of synchronized time is available.
server 127.127.1.0 # local clock
fudge 127.127.1.0 stratum 10
Eu li sobre o burst e iburst e minpoll / maxpoll, então percebo que eles podem não ser necessários, mas não acho que isso tenha alguma coisa a ver com o meu problema atual.
Além disso, por causa de como ele é implantado, esse arquivo de configuração vai precisar de muito trabalho para mudar, então espero que não haja nada que realmente deva ser alterado. Espero que este seja um caso de eu não entender como funciona o NTP.
EDITAR
Portanto, parece que esta é uma duplicata de Esta questão , mas eu não sinto que o pôster tenha uma resposta suficiente, então eu ainda gostaria de saber por que o horário local está sendo preferido em relação ao servidor. Além disso, de acordo com uma das respostas abaixo, tentei usar a palavra-chave prefer na linha do servidor da configuração e reiniciar, mas isso parece não ter tido efeito.
Se eu remover todas as linhas "locais" na configuração como a resposta à outra pergunta sugere, o que acontecerá se o servidor estiver inacessível? O NTP morre ou simplesmente continua tentando?
EDIÇÃO IMPORTANTE -
Ok, normalmente, 10.130.33.201 (o "servidor") não tem acesso à internet e não tem uma fonte de tempo GPS para usar. A parte importante é que todos os dispositivos no sistema têm o mesmo tempo que o servidor, independentemente de quão correta a hora realmente é.
Então, só para ver o que aconteceria, adicionei um dos servidores de pool do NTP ao arquivo de configuração do servidor para que ele tivesse tempo de lá, em vez de obter tempo do local. Agora, ele recebe corretamente o tempo do servidor de horário NTP.
Depois disso, os clientes agora sincronizam com o servidor, em vez de preferir LOCAL (0)
ntpq -p
remote refid st t when poll reach delay offset jitter
==============================================================================
*10.130.33.201 38.229.71.1 3 u 58 64 377 0.216 715621. 1.001
LOCAL(0) .LOCL. 10 l 18 64 377 0.000 0.000 0.001
NOVA PERGUNTA -
Quando meu servidor está usando local (exemplo original que foi dado), parece que os clientes estão dizendo: "Oh, 10.130.33.201 está usando LOCAL (0). Hmm, eu também tenho um servidor LOCAL (0) - I ' Vou usar isso diretamente, em vez de obter as mesmas informações via 10.130.33.201 ".
É esse o caso? Eles estão tentando ir "diretamente para a fonte", que é incorretamente LOCAL (0)? Eu preciso do meu servidor para obter o tempo de LOCAL (0), e eu preciso que os clientes obtenham tempo do servidor. Agora, remover o servidor "local" dos arquivos de configuração do cliente é a única opção, mas eu gostaria de entender por que isso está acontecendo e, se possível, evite alterar suas configurações (a mudança de configuração será muito trabalhosa devido a nosso meio ambiente ...).
Além disso, isso parece outra duplicata sem uma boa resposta.