Causas prováveis de NTPD morrer inesperadamente e soluções

Question

Em um aplicativo da web que usa o s3 para armazenamento de documentos físicos, estamos enfrentando problemas com o NTP, que está continuamente morrendo. Isso parece acontecer uma ou duas vezes por dia. Há muito pouca informação fornecida quando isso ocorre, além de que o arquivo PID existe, mas o serviço está morto quando eu verificar o status.

Alguém pode sugerir causas prováveis de NTPD morrer? Estou assumindo que talvez a deriva do relógio esteja causando a morte, mas não tenho certeza do que causaria isso também. Há mais memória e espaço em disco disponível suficiente.

A última vez que o serviço morreu, esta foi a saída:

Sep  6 06:15:25 vm02 rsyslogd: [origin software="rsyslogd" swVersion="5.8.10" x-pid="988" x-info="http://www.rsyslog.com"] rsyslogd was HUPed
Sep  6 06:17:06 vm02 ntpd[10803]: 0.0.0.0 0618 08 no_sys_peer
Sep  6 08:01:10 vm02 ntpd[10803]: 0.0.0.0 0617 07 panic_stop -28101 s; set clock manually within 1000 s.

    

Answer 1

Eu diria que não há um método de 1 minuto para encontrar o motivo exato.

Tivemos problemas semelhantes antes em nosso ambiente ESXi. Para encurtar a história, descobrimos que o relógio do host do ESXi se movia muito e as VMs convidadas estavam sincronizando o tempo do host ESXi e do servidor NTP upstream. Isso causou NTPd em VMs confusos, portanto, morreu com muita freqüência.

Também encontramos em alguns casos raros que a perda aleatória de pacotes também fez com que o NTPd fosse encerrado porque o tempo de ida e volta entre o servidor e o servidor NTPd upstream é usado para calcular o tempo de drift.

Em dois casos acima, se o NTPd vir um desvio de tempo enorme, por exemplo, mais de 1.000, ele sai por padrão. opção -g ajudará um pouco.

   -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.

Você pode dar uma olhada no log do sistema , que deve ter algumas palavras que podem lhe dar uma dica. Você também pode monitorar a saída "ntpq -p" para ter uma idéia aproximada de como o offset se desenvolve.

    

Answer 2

A mensagem de log indica claramente que o desvio do relógio é o motivo da saída. Soluções possíveis:

• Inicie o ntpd com o sinalizador -g; no entanto, isso não corrigirá a causa raiz, que é a distorção do clock.
• Execute o ntpdate antes de iniciar o ntpd; provavelmente a mesma ressalva.

• Adicione mais fontes de tempo; O NTP precisa de 4-6 fontes para manter uma boa precisão. Uma maneira simples de fazer isso é incluir referências repetidas [0-3] .YOURREGION.pool.ntp.org na sua configuração, por exemplo,

  server 0.au.pool.ntp.org iburst
  server 1.au.pool.ntp.org iburst
  server 2.au.pool.ntp.org iburst
  server 3.au.pool.ntp.org iburst
  
  server 0.au.pool.ntp.org iburst
  server 1.au.pool.ntp.org iburst
  server 2.au.pool.ntp.org iburst
  server 3.au.pool.ntp.org iburst
  

Answer 3

Outra opção que você pode tentar é chrony. Em nossos testes, ele executa de maneira mais estável do que o ntpd e manipula melhor o skew em tempo experiente em ambientes virtuais.

link