Ocasionalmente, observamos diferenças de horário em nossos servidores e confirmamos que:
/etc/init.d/ntp restart then ntpq -p , problema resolvido Primeiramente, ntpq -p retornou ntpq: read: Connection refused , então fui em frente e ps aux | grep ntp não retornou nenhum processo ntp, enquanto outros hosts de trabalho retornaram algo como /usr/sbin/ntpd -p /var/run/ntpd.pid -u 101:103 -g . Parece que o ntpd realmente travou desde que nenhum registro foi visto em / var / log / messages, mas é possível que isso tenha acontecido há muito tempo e que a parte no log já tenha sido rotacionada.
Então eu fui para /etc/init.d/ntp restart e me disseram que o pid velho existia:
Stopping NTP server: ntpdstart-stop-daemon: warning: failed to kill 2124: No such process'.
Starting NTP server: ntpd.
mas tudo voltou ao lugar.
Estamos no Debian 6 Squeeze, mas o problema existe desde o Debian 5 Lenny. Nós instalamos o ntp usando aptitude install ntp . Os servidores estão no Linode VPS (= virtualização Xen), então nós perguntamos a eles, mas eles disseram que não tinham experiência como essa.
Além disso, embora eu não saiba se é apenas uma coincidência ou não, parece que isso acontece apenas em servidores de aplicativos (Ruby on Rails) até agora.
A coisa é, uma vez que o arquivo pid permanece quando o ntpd falha, é muito difícil detectar o travamento e reiniciar com monit ou similar. Devo chamar /etc/init.d/ntp restart de vez em quando pelo cron?
Alguma experiência, soluções, pensamentos?
Se você estiver usando monit, sua FAQ diz que monit verifica se o pid no arquivo pid é válido para detectar situações em que o programa trava e deixa seu arquivo pid para trás.
Se você não estiver usando o monit, então talvez você possa encontrar um script de monitoramento que se comunique diretamente com o ntpd (o nagios possui vários plug-ins ntp que você pode usar / reutilizar)? Se você não consegue se comunicar com ele, provavelmente ele caiu.