O relógio do Linux perde 10 minutos toda semana

Question

Um dos relógios do meu servidor linux perde 10 minutos de vez em quando, quase todas as semanas. Eu atualizo o tempo para que ele fique correto e, embora isso não me incomode de verdade, eu gostaria de corrigi-lo.

Eu tenho pesquisado um pouco. Nada pode ser responsável no crontab, e não consigo encontrar nenhuma mensagem relacionada nos logs. Algumas pessoas parecem usar o ntp para corrigir esse tipo de problema, mas eu prefiro não usar um componente desnecessário nele.

Resultado do uname: Linux unis-monitor 2.6.32-5-686 # 1 SMP seg 25 de fevereiro 01:04:36 UTC 2013 i686 GNU / Linux

Mensagem do gato:

cat messages
Jul 14 06:25:06 unis-monitor rsyslogd: [origin software="rsyslogd" swVersion="4.6.4" x-pid="882" x-info="http://www.rsyslog.com"] rsyslogd was HUPed, type 'lightweight'.
Jul 15 06:25:05 unis-monitor rsyslogd: [origin software="rsyslogd" swVersion="4.6.4" x-pid="882" x-info="http://www.rsyslog.com"] rsyslogd was HUPed, type 'lightweight'.

Syslog do gato

cat syslog
Jul 15 06:25:05 unis-monitor rsyslogd: [origin software="rsyslogd" swVersion="4.6.4" x-pid="882" x-info="http://www.rsyslog.com"] rsyslogd was HUPed, type 'lightweight'.
Jul 15 06:39:01 unis-monitor /USR/SBIN/CRON[15272]: (root) CMD (  [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -type f -cmin +$(/usr/lib/php5/maxlifetime) -delete)
Jul 15 07:09:01 unis-monitor /USR/SBIN/CRON[15465]: (root) CMD (  [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -type f -cmin +$(/usr/lib/php5/maxlifetime) -delete)
Jul 15 07:17:01 unis-monitor /USR/SBIN/CRON[15521]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Jul 15 07:39:01 unis-monitor /USR/SBIN/CRON[15662]: (root) CMD (  [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -type f -cmin +$(/usr/lib/php5/maxlifetime) -delete)
Jul 15 08:09:01 unis-monitor /USR/SBIN/CRON[15855]: (root) CMD (  [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -type f -cmin +$(/usr/lib/php5/maxlifetime) -delete)
Jul 15 08:17:01 unis-monitor /USR/SBIN/CRON[15911]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Jul 15 08:39:01 unis-monitor /USR/SBIN/CRON[16052]: (root) CMD (  [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -type f -cmin +$(/usr/lib/php5/maxlifetime) -delete)
Jul 15 09:09:01 unis-monitor /USR/SBIN/CRON[16273]: (root) CMD (  [ -x /usr/lib/php5/maxlifetime ] && [ -d /var/lib/php5 ] && find /var/lib/php5/ -type f -cmin +$(/usr/lib/php5/maxlifetime) -delete)

Então, se você tem alguma pista de onde procurar ou o que eu poderia usar para monitorar essa mudança de data?

Aqui estão mais algumas informações: o servidor é um servidor virtual hospedado no HyperV em um servidor win 2012. Não sei se isso muda alguma coisa, visto que os outros servidores hospedados não têm esse problema ...

    

Answer 1

O HyperV é a doença, NTPd é a cura.

Onde procurar ou o que eu poderia usar para monitorar essa mudança de data?

Você pode consultar o daemon NTPd (através do cliente ntpq ) para obter a diferença entre o relógio local e o relógio de referência dos servidores NTPd. Mas isso implica realmente executar o NTPd para que você não esteja monitorando suas alterações sozinho, você está monitorando o efeito combinado do seu relógio local em execução e do NTPd mantendo-o em sincronia.

Na verdade, não sei se você pode configurar o NTPd para executar (e fornecer as métricas acima mencionadas), mas não para realmente ajustar o relógio do sistema. Uma maneira diferente, e menos eficiente, seria periodicamente executar (cron?) ntpdate -q contra um conjunto de servidores NTPd de referência e monitorar sua saída, o que lhe dará a diferença entre seu relógio e a referência sem realmente tocar o relógio local. . A saída será assim:

$ ntpdate -q $YOUR_TLD.pool.ntp.org
[... list of queried servers ...]
17 Jul 12:14:11 ntpdate[42868]: adjust time server 109.168.106.59 offset -0.002517 sec

Você pode filtrar o último número e fazer um gráfico para ter uma boa visão de quanto e quando o relógio pula:

$ OFFSET=$( ntpdate -q $YOUR_TLD.pool.ntp.org | grep adjust | awk '{ print $10 }' )
$ echo $OFFSET
0.002970

    

Answer 2

NTP não é um componente desnecessário.

É a única maneira sensata de manter um relógio do sistema atualizado em relação a uma fonte de tempo atômico.

Você deve instalar o NTP, configurá-lo para usar sua fonte local de tempo do pool e tudo ficará bem.

    

Answer 3

Em meus testes, descobri que os relógios de máquina virtual Hyper-V não são confiáveis e frequentemente têm um desvio de relógio que excede 500 ppm . Isso é suficiente para fazer com que o ntpd falhe . Eu tive que mudar para usar chrony nessas VMs para fornecer relógios de parede razoavelmente precisos; O padrão é 1000 ppm para este cenário e pode ser ajustado ainda mais se necessário.

Eu não considero mais o Hyper-V para qualquer aplicativo em que o controle de horas seja especialmente importante.

    

Answer 4

Desvio de clock em um linux vm em execução no Hyper-V é muito comum se você não tiver os componentes de integração corretos instalados e ativados . O Hyper-V ajustará o clock do hardware de qualquer VM que ele executa, mas o Linux por padrão não depende do clock do hardware depois que o sistema é inicializado. Os componentes de integração fornecem ao kernel dicas sobre o tempo real do relógio e elimina esse problema.

Se os componentes de integração não forem uma opção para sua distro, a solução correta é instalar algo como o ntpd e sincronizar com o host do Hyper-V ou o seu clock pool local.

    

Answer 5

O "problema" é que você está executando uma versão do Linux que não suporta infra-estrutura de fonte de tempo plugável. Várias distribuições suportam isso, mas comumente apenas em seus sistemas operacionais de 64 bits, e não em seus 32 bits.

Como outros já mencionaram, o Integration Services permite a sincronização do relógio, mas somente se o PTSI for suportado. A maioria das distros que suportam PTSI já possuem a fonte de alta tensão. Veja se há um adjtimex port / pacote disponível para sua distro.

O uso do NTP é uma alternativa válida, se você não conseguir que o PTSI funcione corretamente. Existem também alguns hacks incluindo o comando tickadj , e alterando as variáveis de inicialização do kernel - isso deve ser evitado.