☰

Por que o tempo muda espontaneamente no debian?

tag-icon • tag-icon linux debian date
Por que o tempo muda espontaneamente no debian?

Debian 8. Sistema host, sem virtualização. Os sistemas de sincronização de tempo estão desativados. ntp, rdate, sdwdate não estão instalados.

# timedatectl
Local time: Thu 2019-08-22 14:02:05 +03
Universal time: Thu 2019-08-22 11:02:05 UTC
RTC time: Thu 2019-08-22 11:00:10
Time zone: Europe/Minsk (+03, +0300)
NTP enabled: no
NTP synchronized: no
RTC in local TZ: no
DST active: n/a

Um segundo depois de definir a hora, ela muda vários minutos.

Exemplos:

# ntpdate 0.ru.pool.ntp.org  && date && sleep 1 && date
22 Aug 14:02:28 ntpdate[31388]: step time server 195.211.77.68 offset -115.009072 sec
Thu Aug 22 14:02:28 +03 2019
Thu Aug 22 14:04:24 +03 2019

# hwclock --hctosys && date && sleep 1 && date
Thu Aug 22 14:01:51 +03 2019
Thu Aug 22 14:03:46 +03 2019

# date -s "2019-08-22 14:04:53" && date && sleep 1 && date
Thu Aug 22 14:04:53 +03 2019
Thu Aug 22 14:04:53 +03 2019
Thu Aug 22 14:06:49 +03 2019

Ao alterar manualmente, as mensagens aparecem nos logs

Aug 22 16:30:50 wisi systemd[1200]: Time has been changed
Aug 22 16:30:50 wisi systemd[1]: Time has been changed
Aug 22 16:32:45 wisi systemd[1200]: Time has been changed
Aug 22 16:32:45 wisi systemd[1]: Time has been changed

aqui as duas primeiras linhas são sobre mudança manual de horário, as duas últimas são sobre o fato de que o sistema “ajustou” o horário de volta.

# ps afx | grep [1]200
 1200 ?        Ss     0:06 /lib/systemd/systemd --user

Tentativas de desabilitartemporizadores.target, time-sync.target, systemd-timesyncdnão têm efeito.

Nos logs do tcpdump, pode-se observar que não há solicitações na 123ª porta durante o "ajuste". O tempo de “ajuste” não é constante e varia, foi observado de 1 a 5 minutos.

O que causou isso e como se livrar dele?

UPD1: @Seth,

Ver o timedatectl após a mudança seria interessante.

# timedatectl && ntpdate 0.ru.pool.ntp.org  && timedatectl && sleep 1 && timedatectl
      Local time: Fri 2019-08-23 14:10:57 +03
  Universal time: Fri 2019-08-23 11:10:57 UTC
        RTC time: Fri 2019-08-23 11:09:19
       Time zone: Europe/Minsk (+03, +0300)
     NTP enabled: no
NTP synchronized: no
 RTC in local TZ: no
      DST active: n/a
23 Aug 14:09:25 ntpdate[19282]: step time server 192.36.143.130 offset -98.695079 sec
      Local time: Fri 2019-08-23 14:09:25 +03
  Universal time: Fri 2019-08-23 11:09:25 UTC
        RTC time: Fri 2019-08-23 11:09:26
       Time zone: Europe/Minsk (+03, +0300)
     NTP enabled: no
NTP synchronized: no
 RTC in local TZ: no
      DST active: n/a
      Local time: Fri 2019-08-23 14:11:05 +03
  Universal time: Fri 2019-08-23 11:11:05 UTC
        RTC time: Fri 2019-08-23 11:09:27
       Time zone: Europe/Minsk (+03, +0300)
     NTP enabled: no
NTP synchronized: no
 RTC in local TZ: no
      DST active: n/a

O que você quer dizer com eles não têm efeito? Você verificou se é um ajuste correto ou não?

Sim, claro, o problema começou quando o serviço padrão foi habilitado. Para o teste, tentei pará-los, mas isso não afetou o resultado.

UPD2

Como teste, desconectei todos os cabos de rede. Tudo está como antes. Mas quaisquer suposições de “rede” podem agora ser excluídas.

Responder1

Oskam retorna a hora ao definido anteriormente.

https://github.com/gfto/oscam/blob/2780c48789c8e1427df4078ea9b06e0b51594bbc/oscam-time.c

#if defined(CLOCKFIX)
    if (tv.tv_sec > lasttime.tv_sec || (tv.tv_sec == lasttime.tv_sec && tv.tv_usec >= lasttime.tv_usec)){ // check for time issues!
        lasttime = tv; // register this valid time 
    }
    else
    {
        tv = lasttime;
        settimeofday(&tv, NULL); // set time back to last known valid time
        //fprintf(stderr, "*** WARNING: BAD TIME AFFECTING WHOLE OSCAM ECM HANDLING, SYSTEMTIME SET TO LAST KNOWN VALID TIME **** \n");
    }

informação relacionada