☰

¿Por qué el tiempo cambia espontáneamente en Debian?

tag-icon • tag-icon linux debian date
¿Por qué el tiempo cambia espontáneamente en Debian?

Debian 8. Sistema host, sin virtualización. Los sistemas de sincronización horaria están deshabilitados. ntp, rdate, sdwdate no están 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

Un segundo después de configurar la hora, cambia varios minutos.

Ejemplos:

# 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

Al cambiar manualmente, aparecen mensajes en los registros.

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

aquí las dos primeras líneas tratan sobre el cambio de hora manual, las dos segundas tratan sobre el hecho de que el sistema “ajustó” la hora hacia atrás.

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

Intentos de desactivartemporizadores.target, time-sync.target, systemd-timesyncdno tiene ningún efecto.

En los registros de tcpdump, se puede ver que no hay solicitudes en el puerto 123 al "ajustar". El tiempo de "ajuste" no es constante y cambia, se observó de 1 a 5 minutos.

¿Qué lo causó y cómo deshacerse de él?

UPD1: @Seth,

Sería interesante ver timedatectl después del cambio.

# 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

¿Qué quieres decir con que no tienen ningún efecto? ¿Verificaste si es un ajuste correcto o no?

Sí, por supuesto, el problema comenzó cuando el servicio predeterminado está habilitado. Para la prueba intenté detenerlos, pero esto no afecta el resultado.

UPD2

Como prueba, desconecté todos los cables de red. Todo es como antes. Pero ahora se puede excluir cualquier supuesto de "red".

Respuesta1

Oskam devuelve el tiempo al establecido previamente.

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");
    }

información relacionada