Eu recomendaria excluir o arquivo de desvio, parar o daemon NTP e executar um ntpdate antes de iniciar o serviço. O que eu entendo é que o relógio do seu hardware tem um problema.
Estação de trabalho RHEL 5. Tem funcionado sem problemas há anos. Eu fiz um 'filhote de cachorro' recentemente e segui com uma boa reinicialização de limpeza. Depois disso, o sistema teve alguns problemas de inicialização: o MySQL recusou-se a iniciar. Ele apenas "...." por 5-10 minutos antes de eu fazer outra inicialização e pular essa etapa (usando 'interativo'). Este foi o único serviço que não queria começar normalmente.
Então, agora que o sistema foi inicializado, descobri que ele não quer ficar sincronizado com o mestre NTP e depois de 48 horas está recusando qualquer SSH que não seja o root.
NTPD: este serviço inicia normalmente e obtém um bloqueio em 4 servidores. Quase imediatamente começa a perder terreno e agora (após 3 dias) está quase 40 horas atrasado. Se eu parar / iniciar o serviço, ele obtém o bloqueio, redefine o relógio do sistema e começa a perder terreno novamente. O 'hwclock' está definido corretamente e mantém seu tempo.
Login: quando eu (re) inicio o servidor ntp eu consigo logar normalmente. Eu assumo este problema é devido a perder a sincronização com o LDAP. Isto parece ser verificado por erros LDAP em / var / log / messages.
Sugestões sobre onde procurar?
ADDENDA: tentou excluir o arquivo 'drift'. Depois de um pouco, é recriado com 0.000.
de / var / log / messages:
Jan 17 06:54:01 aeolus ntpdate[5084]: step time server 129.95.96.10 offset 30.139216 sec
Jan 17 06:54:01 aeolus ntpd[5086]: ntpd [email protected] Tue Oct 25 12:54:17 UTC 2011 (1)
Jan 17 06:54:01 aeolus ntpd[5087]: precision = 1.000 usec
Jan 17 06:54:01 aeolus ntpd[5087]: Listening on interface wildcard, 0.0.0.0#123 Disabled
Jan 17 06:54:01 aeolus ntpd[5087]: Listening on interface wildcard, ::#123 Disabled
Jan 17 06:54:01 aeolus ntpd[5087]: Listening on interface lo, ::1#123 Enabled
Jan 17 06:54:01 aeolus ntpd[5087]: Listening on interface eth0, fe80::213:72ff:fe20:4080#123 Enabled
Jan 17 06:54:01 aeolus ntpd[5087]: Listening on interface lo, 127.0.0.1#123 Enabled
Jan 17 06:54:01 aeolus ntpd[5087]: Listening on interface eth0, 10.127.24.81#123 Enabled
Jan 17 06:54:01 aeolus ntpd[5087]: kernel time sync status 0040
Jan 17 06:54:02 aeolus ntpd[5087]: frequency initialized 0.000 PPM from /var/lib/ntp/drift
Jan 17 06:54:02 aeolus ntpd[5087]: system event 'event_restart' (0x01) status 'sync_alarm, sync_unspec, 1 event, event_unspec' (0xc010)
Você pode ver o deslocamento de 30 segundos. Isso foi depois de cerca de um minuto de operação.
Eu recomendaria excluir o arquivo de desvio, parar o daemon NTP e executar um ntpdate antes de iniciar o serviço. O que eu entendo é que o relógio do seu hardware tem um problema.
Como você deve saber, o ntpd tenta medir o desvio do relógio interno do hardware e ajustar os relógios do sistema de acordo (no caso de o servidor não poder ser contatado e evitar sincronizações excessivas). O valor do desvio é armazenado em um arquivo; geralmente /etc/ntp/drift (depende da sua distro). Parece que, de alguma forma, um valor errado é anotado ali; ou alguns outros parâmetros alterados (consumo de energia, etc.) influenciaram as características do hardware de tal maneira que esse valor de desvio armazenado não está mais correto.
Pare o daemon, renomeie / remova o arquivo (ou apenas esvazie-o) e inicie o daemon novamente. Ele medirá o desvio do zero nos próximos dias e agirá de acordo.
LDAP e SSH (entre outros serviços de login), contam com os sistemas envolvidos não tendo muita discrepância de seus relógios de sistema, então se você estiver fora por 40 horas, é completamente natural que eles fiquem chateados. :)