Systemuhrzeit langsam

[ServiceLinuxStart]

Hallo, irgendwas stimmt mit meiner Systemuhrzeit nicht.

Ich ignoriere NTP erstmal und mache folgendes.
Setze die exakte uhrzeit mit:

date -s "2020-07-08 21:09:20" && hwclock -w && timedatectl
Ausgabe:
Local time: Mi 2020-07-08 21:09:20 CEST
Universal time: Mi 2020-07-08 21:09:20 UTC
RTC time: Mi 2020-07-08 21:09:20
Time zone: Europe/Berlin (CEST, +0200)
System clock synchronized: no
NTP service: inactive
RTC in local TZ: no

10min später gebe ich erneut: timedatectl
Local time: Mi 2020-07-08 21:17:45 CEST
Universal time: Mi 2020-07-08 21:17:45 UTC
RTC time: Mi 2020-07-08 21:19:20
Time zone: Europe/Berlin (CEST, +0200)
System clock synchronized: no
NTP service: inactive
RTC in local TZ: no

Warum läuft meine Systemuhrzeit langsamer?

[mat6937]

10min später gebe ich erneut: timedatectl

Code: Alles auswählen

Local time: Mi 2020-07-08 21:17:45 CEST
Universal time: Mi 2020-07-08 21:17:45 UTC
RTC time: Mi 2020-07-08 21:19:20

Warum läuft meine Systemuhrzeit langsamer?

Wie ist jetzt die Ausgabe von:

Code: Alles auswählen

rdate -4pnu 2.pool.ntp.org && timedatectl

?

[ServiceLinuxStart]

Kann ich nicht sagen. System ist ein Offlinesystem und soll unabhängig von NTP funktionieren. Zumindest sollte die Systemzeit identisch mit der HW Zeit sein.
Cron alle 10min mit hwclock -s laufen zu lassen ist auch nix.

[michaa7]

Ist das bejahrte HW mit ner dementsprechenden Knopfzelle?

[ServiceLinuxStart]

Ist das bejahrte HW mit ner dementsprechenden Knopfzelle?

Ja, ne 2032 ... Dachte, die ist dazu da, wenn kein Strom fließt um die Uhr am Laufen zu halte. Aber das System ist an..

[MSfree]

Welche der beiden Uhren hat denn die korrekte Zeit?

[ServiceLinuxStart]

Welche der beiden Uhren hat denn die korrekte Zeit?

Die RTC Zeit zeigt korrekt an.

[MSfree]

Code: Alles auswählen

timedatectl timesync-status

?

[ServiceLinuxStart]

Code: Alles auswählen

timedatectl timesync-status

?

Code: Alles auswählen

Failed to query server: Unit dbus-org.freedesktop.timesync1.service not found.

[fischig]

Seit wann ist CEST = UTC? Schätze, das Zeitmanagement stimmt hinten und vorne nicht.

[ServiceLinuxStart]

Seit wann ist CEST = UTC? Schätze, das Zeitmanagement stimmt hinten und vorne nicht.

Sorry falsch ausgedrückt. Die exate Zeit ist natürlich RTC time +02.00. Mich interessiert, warum die Systemzeit 7 sekunden pro Minute verzögerung hat. Ich hab jetzt tatsächlich ein Cronjob (hwclock -s), der jede Stunde die Systemuhrzeit korrigiert. Ist natürlich keine Dauerlösung. Auf dem System läuft Netdata, Grafana, Datenbanken, OVM, VMs. Ich brauch ne Uhr die Funktioniert. Selbst NTP würde mir da nicht helfen.

[MSfree]

Mich interessiert, warum die Systemzeit 7 sekunden pro Minute verzögerung hat.

Ich glaube, fischic wolltet auf die Ausgabe deines ursprünglichen Posts hinaus:

Code: Alles auswählen

date -s "2020-07-08 21:09:20" && hwclock -w && timedatectl
               Local time: Mi 2020-07-08 21:09:20 CEST
           Universal time: Mi 2020-07-08 21:09:20 UTC
                 RTC time: Mi 2020-07-08 21:09:20
                Time zone: Europe/Berlin (CEST, +0200)
System clock synchronized: no
              NTP service: inactive
          RTC in local TZ: no

Hier ist klar zu erkennen, daß UTC und CEST identisch sind, was sie aber wegen der Zeitzone (CEST, +0200) nicht sein dürften. Vermutlich wird deshalb die Uhr stark verlangsamt, damit sie allmählich auf die 2 Stunden Zeitdifferenz zwischen UTC und CEST driften kann.

[ServiceLinuxStart]

Mich interessiert, warum die Systemzeit 7 sekunden pro Minute verzögerung hat.

Ich glaube, fischic wolltet auf die Ausgabe deines ursprünglichen Posts hinaus:

Code: Alles auswählen

date -s "2020-07-08 21:09:20" && hwclock -w && timedatectl
               Local time: Mi 2020-07-08 21:09:20 CEST
           Universal time: Mi 2020-07-08 21:09:20 UTC
                 RTC time: Mi 2020-07-08 21:09:20
                Time zone: Europe/Berlin (CEST, +0200)
System clock synchronized: no
              NTP service: inactive
          RTC in local TZ: no

Hier ist klar zu erkennen, daß UTC und CEST identisch sind, was sie aber wegen der Zeitzone (CEST, +0200) nicht sein dürften. Vermutlich wird deshalb die Uhr stark verlangsamt, damit sie allmählich auf die 2 Stunden Zeitdifferenz zwischen UTC und CEST driften kann.

Code: Alles auswählen

root@S01:~# 	timedatectl
			Local time: 		Do 2020-07-09 18:19:58 CEST
			Universal time: 	Do 2020-07-09 16:19:58 UTC
			RTC time: 		Do 2020-07-09 16:21:58
			Time zone: 		Europe/Berlin (CEST, +0200)
			System clock synchronized: no
			NTP service: 		inactive
			RTC in local TZ: 	no
root@S01:~# 	hwclock -s
root@S01:~# 	timedatectl
			Local time: 		Do 2020-07-09 18:22:06 CEST
           		Universal time: 	Do 2020-07-09 16:22:06 UTC
            		RTC time: 		Do 2020-07-09 16:22:06
            		Time zone: 		Europe/Berlin (CEST, +0200)
			System clock synchronized: no
            		NTP service: 		inactive
          		RTC in local TZ: 	no
          		
          		####exakt 6 min später
          		
root@S01:~# 	timedatectl
               		Local time: 		Do 2020-07-09 18:27:33 CEST
           		Universal time: 	Do 2020-07-09 16:27:33 UTC
                 	RTC time: 		Do 2020-07-09 16:28:06
                	Time zone: 		Europe/Berlin (CEST, +0200)
			System clock synchronized: no
              		NTP service: 		inactive
          		RTC in local TZ: 	no

EDIT: Im Anfangspost hatte ich offenbar ein copy/paste fehler

[MSfree]

EDIT: Im Anfangspost hatte ich offenbar ein copy/paste fehler

Dann ist diese Gangrate allerdings dubios.

Ich habe hier im LAN natürlich einen NTP laufen. Da sehe ich bei

Code: Alles auswählen

timedatectl timesync-status
       Server: 159.69.4.181 (2.debian.pool.ntp.org)
Poll interval: 8min 32s (min: 32s; max 34min 8s)
         Leap: normal
      Version: 4
      Stratum: 2
    Reference: C0356768
    Precision: 1us (-23)
Root distance: 33.850ms (max: 5s)
       Offset: +2.135ms
        Delay: 393us
       Jitter: 801us
 Packet count: 5
    Frequency: +7.936ppm

also eine Abweichung zwischen dem "obersten Boß" NTP und einem meiner Clients und rund 8ppm Gangrate, was also ca. 7s pro Tag entspricht.

Entweder dein Rechner ist komisch über- oder untertaktet, so daß die Taktfrequenz zu einer falschen Systemzeit führt. Oder es steht noch irgendwo im System eine irgendwie vormals bestimmte Gangrate auf einer Datei, die beim Boot gelesen und angewendet wird. Ich habe aber mein System schon nach so einer Datei durchsucht und nichts gefunden.

Wenn man einen laufenden NTP hat, wird unter /var/lib/ntp/ eine Datei ntp.drift angelegt, die fehlt aber, wenn kein NTP läuft.

Ich bin ehrlich gesagt ein wenig ratlos.

[Tintom]

Der Drift ist mal heftig...
Was ist das für Hardware? Der Taktgeber für die Systemzeit basiert auf Interrupt-Timings, es gibt im Kernel unterschiedliche Implementierungen. Gibt es Fehlermeldungen zu Interrupt-Geschichten im Bootlog? Die unterschiedlichen Implementierungen sind unter cat /sys/bus/clocksource/devices/clocksource0/available_clocksource zu finden und echo $timer > /sys/bus/clocksource/devices/clocksource0/current_clocksource kann zum Setzen eines anderen Timers benutzt werden.

Bei stackoverflow hieß es noch, stark ausgelastete Systeme oder Systeme, die hinter einer USV hängen, könnten solches Verhalten erklären.

[ServiceLinuxStart]

Ich bin ehrlich gesagt ein wenig ratlos.

Dito

Der Drift ist mal heftig...
Was ist das für Hardware?

ASUS Pro C621, Xeon Gold 6136, 128gb ecc

Werd heute Nacht mal alles Herunterfahren und Neustarten. Ich war selten so Ratlos...

[MSfree]

Bei stackoverflow hieß es noch, stark ausgelastete Systeme oder Systeme, die hinter einer USV hängen, könnten solches Verhalten erklären.

USV halte ich für ein eigenartiges Argument. Aber dazu fällt mir gerade ein, daß Virtuelle Maschinen auch solches Verhalten zeigen können, wenn auch nicht so stark, wie in diesem Fall.

[ServiceLinuxStart]

Problem gefunden:
Server neu gestartet. Uhrzeit im BIOS manuel aktualisiert. Server läuft, Local time / Universal time / RTC time stimmen. Alles gestartet, VMs/Telemetrie, Uhrzeit weiterhin synchron und richtig. Verstelle ich jedoch die Uhrzeit über OVM web, fängt sie an asynchron zu laufen. Local time verliert dann 7 sec pro Minute, egal was ich dann mache. Die Uhrzeit läuft nicht mehr synchron, bis zum Neustart. Warum passiert das: ...Keine Ahnung!

[reox]

Verstelle ich jedoch die Uhrzeit über OVM web, fängt sie an asynchron zu laufen

Schuss ins blaue: Das ding startet einen eigenen job und stellt dir die zeit immer zurück weil es glaubt alleine auf dem system zu sein?

[MSfree]

Verstelle ich jedoch die Uhrzeit über OVM web, fängt sie an asynchron zu laufen.

Vielleicht solltest du einen Bugreport bei OMV machen.
https://github.com/openmediavault/openmediavault/issues

[Tintom]

Ich habe erst an einen Typo gedacht, aber weil im Thread überall 'OVM' statt 'OMV' stand, habe ich an den gleichnamigen Hoster gedacht.

Wenn aber tatsächlich Openmediavault installiert ist sieht die Sache anders aus. OMV verwendet anscheinend chrony zur Zeitsynchronisation, welches wiederum in /var/lib/chrony seine Daten speichert. Liegt da irgendwo noch Driftfile herum? Existiert die Datei /etc/adjtime?

[ServiceLinuxStart]

OMV ist natürlich richtig
Werde demnächst ein Bugreport machen.

Ich bedanke mich ganz herzlich.

[dufty2]

Frequency: +7.936ppm
also eine Abweichung zwischen dem "obersten Boß" NTP und einem meiner Clients und rund 8ppm Gangrate, was also ca. 7s pro Tag entspricht.

Also ganz so viel ist nun auch wieder nicht
60*60*24/1000000*7.936 s ~= 0.7 Sekunden (pro Tag)