O famoso NTPd, por padrão, não ajusta o tempo se ele tiver mais de 1000 s, presumindo que há um problema sistêmico com o qual ele não deve se envolver. Isso de man ntpd :
-g Normally, ntpd exits with a message to the system log if the offset exceeds the panic threshold, which is 1000 s by default. This option allows the time to be set to any value without restriction; however, this can happen only once. If the threshold is exceeded after that, ntpd will exit with a message to the system log. This option can be used with the -q and -x options. See the tinker command for other options.
Um problema é que os relógios da BIOS no Reino Unido costumam demorar uma hora, devido a mal-entendidos sobre se o BIOS está no UTC ou no horário de verão. Eu imagino que o problema piora à medida que sua longitude aumenta de Greenwich.
Portanto, há também um comando ntpdate , que coloca o relógio do sistema em alinhamento com um servidor NTP, de uma maneira não sutil que tende a incomodar muitos serviços em execução. Eu acredito que antecede a adição do sinal -g ao ntpd.
Assim, para veteranos como eu, o protocolo de inicialização completo para ntpd envolve o uso de ntpdate para forçar a sincronização do relógio - com base em que é mais seguro fazer quando o sistema é iniciado - seguido por iniciar ntpd para mantê-lo lá. /etc/ntp/step-tickers controla qual servidor é usado para fazer o ntpdate . Eu geralmente listo um dos meus ntp.conf servidores lá.
Para confundir ainda mais o assunto, o script de inicialização ntpdate no CentOS6 procurará em ntp.conf por um ticker de inicialização se um não estiver listado em step-tickers . Portanto, embora seja uma boa prática garantir que ntpd não fique alto nem seco (tentando sincronizar um relógio do sistema que esteja muito longe), entre os scripts de inicialização modernos e o -g flag to ntpd , step-tickers é realmente uma relíquia histórica, sem função necessária em uma distro moderna. Mas também sou uma relíquia histórica e continuo a usá-la.