☰

Warum ändert sich die Zeit in Debian spontan?

tag-icon • tag-icon linux debian date
Warum ändert sich die Zeit in Debian spontan?

Debian 8. Hostsystem, keine Virtualisierung. Zeitsynchronisierungssysteme sind deaktiviert. ntp, rdate, sdwdate sind nicht installiert.

# 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

Eine Sekunde nach dem Einstellen der Uhrzeit ändert sich diese um mehrere Minuten.

Beispiele:

# 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

Bei manueller Änderung erscheinen Meldungen in den Protokollen

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

hier beziehen sich die ersten beiden Zeilen auf die manuelle Zeitumstellung, die zweiten beiden darauf, dass das System die Zeit „zurückgestellt“ hat.

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

Versuche zur DeaktivierungTimer.target, Zeit-Sync.target, systemd-timesyncdhaben keine Wirkung.

In den TCPdump-Protokollen ist zu sehen, dass beim „Anpassen“ keine Anfragen auf dem 123. Port vorliegen. Die Zeit der „Anpassung“ ist nicht konstant und ändert sich, sie wurde von 1 bis 5 Minuten beobachtet.

Was sind die Ursachen und wie wird man es los?

UPD1: @Seth,

Es wäre interessant, timedatectl nach der Änderung zu sehen.

# 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

Was meinst du damit, dass sie keine Wirkung haben? Hast du überprüft, ob die Einstellung korrekt ist oder nicht?

Ja, natürlich, das Problem begann, als der Standarddienst aktiviert wurde. Zum Test habe ich versucht, sie zu stoppen, aber dies hat keinen Einfluss auf das Ergebnis.

UPD2

Ich habe testweise alle Netzwerkkabel abgezogen. Alles ist wie vorher. Jegliche "Netzwerk"-Annahmen können nun aber ausgeschlossen werden.

Antwort1

Oskam stellt die Zeit auf die zuvor eingestellte Zeit zurück.

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

verwandte Informationen