Portanto, estou tentando depurar minha configuração atual do NTP e constatou que o deslocamento do meu único servidor configurado é superior a 3 segundos e não está sendo ajustado. O asterisco no LOCAL (0) na saída ntpq parece indicar que o sistema está sincronizando felizmente consigo mesmo, em vez do servidor 10.130.33.201 (que é outra caixa linux em nosso sistema com a qual 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, por isso 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 esses podem não ser necessários, mas acho que isso não tem nada a ver com o meu problema atual.
Além disso, devido à maneira como ele é implantado, esse arquivo de configuração levará muito trabalho para mudar, então espero que não exista nada que realmente precise ser alterado. Espero que este seja um caso em que eu não entenda como o NTP funciona.
EDIT -
Portanto, parece que esta é uma duplicata desta pergunta , mas não acho que o pôster tenha uma resposta suficiente; portanto, ainda gostaria de saber por que a hora local está sendo preferida ao servidor. Além disso, conforme uma das respostas abaixo, tentei usar a preferpalavra-chave na linha do servidor de configuração e reinicialização, mas isso não parece ter tido efeito.
Se eu remover todas as linhas "locais" na configuração, como sugerem as respostas para a outra pergunta, o que acontecerá se o servidor estiver inacessível? O NTP morre ou continua tentando?
EDIÇÃO IMPORTANTE -
Ok, normalmente, 10.130.33.201 (O "servidor") não tem acesso à Internet e não possui uma fonte de tempo GPS para usar. A parte importante é que todos os dispositivos no sistema tenham o mesmo horário que o servidor, independentemente de quão correto seja esse horário.
Portanto, apenas para ver o que aconteceria, adicionei um dos servidores de pool NTP ao arquivo de configuração do servidor para obter tempo a partir daí e não local. Agora ele obtém tempo corretamente do servidor de horário NTP.
Depois disso, os clientes agora sincronizam com o servidor, em vez de preferirem 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) - - Vou usar isso diretamente, em vez de obter as mesmas informações em 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 tempo de LOCAL (0) e dos clientes para obter tempo do servidor. No momento, 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, evitar alterar suas configurações (a alteração da configuração será muito trabalhosa devido a Nosso ambiente...).
Além disso, isso parece outra duplicata sem uma boa resposta.