Debian liest Hardware Zeit inkorrekt

[micha81929]

Hallo, ich bin relativ neu bei Debian und Linux. Das folgende Problem habe ich seit der Installation (Debian Gnome weezy unter einem GRUB Doppel-Boot mit Windows 10) for einem Jahr, und trotz verschiedener Lösungsvorschläge aus englischen Diskussiongruppen bin ich keinen Schritt weiter gekommen.
Die Diagnose ist, dass Debian systematisch die Systemzeit um Stunden und Tage nach vorne datiert. Wenn ich die Zeit (CEST) und das Datum manuel korrigiere, stimmt es für die jeweilige Session. Wenn ich nach >12 STunden (typisch über NAcht) mich wieder neu bei Debian anmelde, ist Datum und Zeit wie gesagt um Tage und Stunden in die Zukunft verschoben (auch die HArdware-Zeit).
Ich habe auf Empfehlung hin NTS installiert, und in etc/default/rcS die UTC=no option gesetzt. Es hat aber keinerlei Veränderung gebracht.
Heute habe ich etwas sehr merkwürdiges beobachtet: Wenn ich aus Linux die HArdwarezeit abrufe (hwclock -D), steht da mit korrektem Datum eine Uhrzeit von 89:18:23 . Die zusätzlichen 68 Stunden zur tatsächlichen Uhrzeit 21:18:23 entsprechen genau den 2 TAgen und 20 Stunden, die die Linux Systemzeit in die Zukunft verschoben ist.

root@Michas-BigAsus:/home/michael# hwclock -D
hwclock from util-linux 2.20.1
Using /dev interface to clock.
Last drift adjustment done at 1464992937 seconds after 1969
Last calibration done at 1464992937 seconds after 1969
Hardware clock is on local time
Assuming hardware clock is kept in local time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2016/06/04 89:18:23
Hw clock time : 2016/06/07 17:18:23 = 1465312703 seconds since 1969
Di 07 Jun 2016 17:18:23 CEST -0.375491 seconds
root@Michas-BigAsus:/home/michael#

Das Problem ist aber nicht die HArdware-Clock. Wenn ich den REchner in Windows boote, ist HArdware und Systemzeit immer identisch und korrekt. Ich habe irgendwie den Eindruck, dass Linux aus irgendeinem unerfindlichem Grund die HArdwarezeit verändert

In etc/adjtime steht als letzte gemessene Zeitdifferenz zwischen Systemzeit und Hardwarezeit 3.2 Stunden. Sollte ich diese Zeitdifferenz vielleicht einfach mal auf 0 korrigieren ? Wenn es irgendwo die Option gibt, Linux generell daran zu hindern, dass es die HArdwarezeit verändert, würde ich gerne wissen wo ich das einstellen kann.

Herzlich Grüsse für Eure Ratschläge

Michael

[spiralnebelverdreher]

Hallo und willkommen hier im Forum!

Zu deinem Problem habe ich eine Frage: Aus welchen Quellen bezieht dein debian sein Uhrzeit? Was ist da als ntp-Dienst aktiv? Kannst du bspw. mit

Code: Alles auswählen

ps ax | grep ntp

herausfinden. Falls nptd läuft, wie sieht die Datei /etc/ntp.conf aus?

Nächste Frage: Welche Uhrzeit steht in deinem BIOS nach dem Herunterfahren von Windows bzw. Linux?

Übernächste Frage: Ist in deinem Rechner oder in einem Rechner in deinem Netzwerk ein sogenannter DCF77-Empfänger zu finden? Diese Dinger sind heute nicht mehr üblich, aber vor 20+ Jahren waren sie eine beliebte Zeitquelle und sind u.U. empfindlich für HF-Einstreuungen mit hässlichen Uhrzeiteffekten.

[NAB]

Hast du mal nach einem BIOS-Update geguckt?

[rendegast]

Ein walkaround wäre vielleicht,
dem ntp-Client beim Start die Korrektur auch großer Differenzen zu erlauben.

Im Falle von openntpd wäre das die Option '-s'.
Beim ntp ist standardmäßig schon '-g' gesetzt.
Bei chrony bleibt wohl nur die authorisierte (siehe dazu in dessen init-Skript) Korrektur per 'makestep'.

[towo]

Ein besserer Workaround wäre, unter Windows auch UTC zu benutzen.

[guennid]

Ein besserer Workaround wäre, unter Windows auch UTC zu benutzen.

Das würde aber auch nicht erklären, wieso er in Linux eine um Tage verschobene Zeit findet.

Wenn ich den Rechner in Windows boote, ist Hardware und Systemzeit immer [...] korrekt.

Das glaube ich ihm erstmal nicht.

Vielleicht sollte er, statt dieses verschwurbelten

Code: Alles auswählen

Last drift adjustment done at 1464992937 seconds after 1969
Last calibration done at 1464992937 seconds after 1969

mal zeigen, was denn sein wheezy tatsächlich als aktuelle (System-)Zeit via

Code: Alles auswählen

date

ausspuckt. Und das dann mit der aktuellen Zeitangabe in windows vergleichen.

Grüße, Günther

[micha81929]

Ich habe vor ein paar Stunden die Bios-/Hardwarezeit wieder auf die lokale Zeit korrigiert (weil sie inzwischen schon wieder ca. 12 Stunden in der Zukunft lag).

Im Augenblick zeigt die Linux-Systemzeit deshalb auch den richtigen Wert:

root@Michas-BigAsus:/home/michael# date
Di 7. Jun 00:21:29 CEST 2016

und hwclock ebenfalls:
root@Michas-BigAsus:/home/michael# hwclock -D
hwclock from util-linux 2.20.1
Using /dev interface to clock.
Last drift adjustment done at 1465279895 seconds after 1969
Last calibration done at 1465279895 seconds after 1969
Hardware clock is on local time
Assuming hardware clock is kept in local time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2016/06/07 00:21:41
Hw clock time : 2016/06/07 00:21:41 = 1465251701 seconds since 1969
Di 07 Jun 2016 00:21:41 CEST -0.282643 seconds

In dem etc/adjtime file steht aber immer noch eine Zeitkorrektur von fast 46000 sekunden (fast 13 Stunden):

47599.159535 1465279895 0.000000
1465279895
LOCAL

Ich werde mal bis morgen NAchmittag warten, wie sich die Werte entwickeln, und dann ein Update schicken.

beste Grüsse
Michael

[micha81929]

Hallo und willkommen hier im Forum!

Zu deinem Problem habe ich eine Frage: Aus welchen Quellen bezieht dein debian sein Uhrzeit? Was ist da als ntp-Dienst aktiv? Kannst du bspw. mit

Code: Alles auswählen

ps ax | grep ntp

herausfinden. Falls nptd läuft, wie sieht die Datei /etc/ntp.conf aus?
.

Das ist die ntp.conf datei:

# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help

driftfile /var/lib/ntp/ntp.drift


# Enable this if you want statistics to be logged.
#statsdir /var/log/ntpstats/

statistics loopstats peerstats clockstats
filegen loopstats file loopstats type day enable
filegen peerstats file peerstats type day enable
filegen clockstats file clockstats type day enable


# You do need to talk to an NTP server or two (or three).
# diese Zeilen wurden von STRATO vorgeschlagen
server ntp1.rz-ip.net
server ntp2.rz-ip.net
driftfile /var/lib/ntp/ntp.drift
logfile /var/log/ntp.log
logconfig =all

# pool.ntp.org maps to about 1000 low-stratum NTP servers. Your server will
# pick a different set every time it starts up. Please consider joining the
# pool: <http://www.pool.ntp.org/join.html>
server 0.debian.pool.ntp.org iburst
server 1.debian.pool.ntp.org iburst
server 2.debian.pool.ntp.org iburst
server 3.debian.pool.ntp.org iburst


# Access control configuration; see /usr/share/doc/ntp-doc/html/accopt.html for
# details. The web page <http://support.ntp.org/bin/view/Support ... strictions>
# might also be helpful.
#
# Note that "restrict" applies to both servers and clients, so a configuration
# that might be intended to block requests from certain clients could also end
# up blocking replies from your own upstream servers.

# By default, exchange time with everybody, but don't allow configuration.
restrict -4 default kod notrap nomodify nopeer noquery
restrict -6 default kod notrap nomodify nopeer noquery

# Local users may interrogate the ntp server more closely.
restrict 127.0.0.1
restrict ::1

# Clients from this (example!) subnet have unlimited access, but only if
# cryptographically authenticated.
#restrict 192.168.123.0 mask 255.255.255.0 notrust


# If you want to provide time to your local subnet, change the next line.
# (Again, the address is an example only.)
#broadcast 192.168.123.255

# If you want to listen to time broadcasts on your local subnet, de-comment the
# next lines. Please do this only if you trust everybody on the network!
#disable auth
#broadcastclient

[micha81929]

Hast du mal nach einem BIOS-Update geguckt?

Ich hatte bisher keinen Anlass das BIOS upzudaten. Diese Veränderungen in der Hardware-Zeit und damit in der Systemzeit passiert ja nur, wenn ich von dem Dual-Boot aus Linux starte und das an eine Weile läuft.
Verschiedentlich wurde schon diskutiert, dass die Verschiebungen der Linux-Systemzeit (und von dort aus dann in einem zweiten Schritt die Hardware Zeit) durch Unterschiede in den Zeitzonen (UTC zu CEST) zustande kommt. Allerdings ist die Differenz ja konstant 2 Stunden, wohingegen die Veränderungen in der Linux-Systemzeit garkeine vollen Stunden sind, und sich ausserdem immer weiter vergrössert.

Ich hatte in einem anderen Forum ähnliche Beobachtungen (unter openSUSE) gelesen.
http://www.linuxforen.de/forums/showthr ... te-adjtime

beste Grüsse
Michael

[micha81929]

Hallo und willkommen hier im Forum!

Zu deinem Problem habe ich eine Frage: Aus welchen Quellen bezieht dein debian sein Uhrzeit? Was ist da als ntp-Dienst aktiv? Kannst du bspw. mit

Code: Alles auswählen

ps ax | grep ntp

herausfinden. Falls nptd läuft, wie sieht die Datei /etc/ntp.conf aus?

Nächste Frage: Welche Uhrzeit steht in deinem BIOS nach dem Herunterfahren von Windows bzw. Linux?

Übernächste Frage: Ist in deinem Rechner oder in einem Rechner in deinem Netzwerk ein sogenannter DCF77-Empfänger zu finden? Diese Dinger sind heute nicht mehr üblich, aber vor 20+ Jahren waren sie eine beliebte Zeitquelle und sind u.U. empfindlich für HF-Einstreuungen mit hässlichen Uhrzeiteffekten.

Hallo Spiralnebelverdreher,

Ursprünglich hatte ich Debian installiert so dass es seine Systemzeit aus der Hardwarezeit bezog. Vor ein paar Tagen habe ich NTP installiert, aber die Verschiebung der Systemzeit in die Zukunft passiert nach wie vor.
Nach Herunterfahren von Windows ist die Bios-Zeit immer korrekt. Wenn dagegen Linux eine Weile gelaufen ist, kommt es nach dem Runterfahren zu der beschriebenen Verschiebung der Bios-Zeit in die Zukunft.
Es ist definitiv kein DCF77 Empfänger im Rechner.

beste Grüsse
Michael

[NAB]

Ich hatte bisher keinen Anlass das BIOS upzudaten. Diese Veränderungen in der Hardware-Zeit und damit in der Systemzeit passiert ja nur, wenn ich von dem Dual-Boot aus Linux starte und das an eine Weile läuft.
Verschiedentlich wurde schon diskutiert, dass die Verschiebungen der Linux-Systemzeit (und von dort aus dann in einem zweiten Schritt die Hardware Zeit) durch Unterschiede in den Zeitzonen (UTC zu CEST) zustande kommt. Allerdings ist die Differenz ja konstant 2 Stunden, wohingegen die Veränderungen in der Linux-Systemzeit garkeine vollen Stunden sind, und sich ausserdem immer weiter vergrössert.

Ich hatte dich erst so verstanden, dass Linux aus deiner Hardware-Uhr konstant eine Differenz von +68 Stunden herausliest ... das hätte ich ggf. für einen Fehler in irgendeiner ACPI-Tabelle im BIOS gehalten.

Jetzt verstehe ich dich allerdings so, dass die Hardware-Uhr unter Linux auf magische Weise konstant zu schnell zu gehen scheint und die Abweichung immer größer wird ... in der Tat, da würde auch ich eher die Schuld auf Linux schieben als auf das BIOS.

Edit: Ach, kannst du mit diesem Thread etwas anfangen? (Ich nämlich nicht)
http://www.linuxquestions.org/questions ... ot-844338/
Er berichtet ebenfalls über einen massive time drift. Im letzten Posting verweist er auf einen anderen Thread als Lösung ... die darin besteht, dass er sich eine neue initrd baut ... anscheinend hat er vorher die eines anderen Users verwendet. Immerhin schließe ich daraus, dass man solche Phänomene durch eine unvollständige initrd auslösen kann ... wenn ich auch nicht weiß wie. Es scheint um die Unterschiede zwischen AMD und Intel zu gehen.

[smutbert]

Hast du schon einmal ein anderes Linux-System, zB ein Live-System gestartet um zu sehen ob das die Uhr ebenfalls falsch ausliest?

und nur als kleiner Hinweis:
Bei Wheezy wählt man afaik nicht mehr in der »/etc/default/rcS« sondern in »/etc/adjtime« zwischen lokaler Zeit und UTC für die Hardwareuhr. (Wie towo würde ich allerdings zuerst Windows beibringen die Hardwareuhr auf UTC zu stellen und auch Linux so konfigurieren, auch wenn das am Problem vielleicht/vermutlich gar nichts ändert.)

[spiralnebelverdreher]

Das ist die ntp.conf datei:

# /etc/ntp.conf, configuration for ntpd; see ntp.conf(5) for help
driftfile /var/lib/ntp/ntp.drift
# You do need to talk to an NTP server or two (or three).
# diese Zeilen wurden von STRATO vorgeschlagen
server ntp1.rz-ip.net
server ntp2.rz-ip.net
driftfile /var/lib/ntp/ntp.drift
logfile /var/log/ntp.log
logconfig =all
# pool.ntp.org maps to about 1000 low-stratum NTP servers. Your server will
# pick a different set every time it starts up. Please consider joining the
# pool: <http://www.pool.ntp.org/join.html>
server 0.debian.pool.ntp.org iburst
server 1.debian.pool.ntp.org iburst
server 2.debian.pool.ntp.org iburst
server 3.debian.pool.ntp.org iburst

Nach deiner Fehlerbeschreibung habe ich die Vermutung, dass deine Hardwareclock (BIOS Batterie alt?) einen erheblichen Fehlgang hat sowie dass der ntp-Daemon unter debian nicht (oder nicht richtig) läuft, während er unter Windows aktiviert ist und die HW-Uhr damit immer wieder auf die "richtige" zeit gesetzt wird.

Du hast leider die Ausgabe von

Code: Alles auswählen

ps ax | grep ntp

nicht gepostet. Es sollte da bspw. "ntpd" oder "ntpdate" in der Pozessliste stehen.
Was ergibt die Ausgabe von

Code: Alles auswählen

ntpq -p

Und was steht in der Datei /var/log/ntp.log ?

Falls der Daemon nptd oder nptdate läuft, kann es sein dass er dennoch dein Uhrzeit nicht korrigiert, weil sie von der HW-Zeit zu weit (mehr als 100s) entfernt ist. Siehe auch http://www.pool.ntp.org/de/use.html

Zudem wundert mich, dass in deiner ntp.conf Datei unter anderem STRATO Server eingetragen sind. Hätte ich bei einem gehosteten Server des Anbieters STRATO so erwartet, aber Linux / Windows auf einem Rechner hört sich eher nach Kiste zu Hause an. Erstmal nicht schlimm bzw sogar gut, dass STRATO ntp-Server für die Allgemeinheit betreibt und du diese benutzt. Wie gesagt, der Weg dieser Zeilen in deinen Rechner wundert mich.

[guennid]

Das Posten realer Zeiten ist offenbar nicht so das Ding des Threadstarters. Und wenn ihr weiter Lust habt, im Nebel herumzustochern, ... ich eigentlich nicht.

Statt blind mit Programmen, welche die Zeit aus dem Netz holen, herumzufummeln, möchte ich erst mal sehen, was sich da tatsächlich auf der Maschine abspielt. Und insofern läuft gar nichts, bevor er die Bios-Uhr nicht auf UTC und den Rechner vom Netz genommen hat. Und dann mal postet, was Windows und sein Debian daraus macht. Jedes Betriebssystem holt sich die Zeit erst mal von der Bios-Uhr, wenn es keine andere findet.

Grüße, Günther

[micha81929]

Hallo, vielen Dank für die verschiedenen Tips, die ich alle mal Stück für Stück austesten werden.

Nur soviel zur Aktualisierung: Debian wheezy lief seit 20 Stunden (seitdem ich die Bios- und die Systemzeit auf die richtigen Werte gestellt hatte) im suspend mode.
Jetzt steht die Systemzeit auf 15:42 Uhr Freitag den 10.6. (d.h. fast 70 Stunden in der Zukunft !!!!)

root@Michas-BigAsus:/home/michael# date
Fr 10. Jun 15:42:32 CEST 2016

hwclock kann jetzt garkeine Zeit mehr auslesen:
root@Michas-BigAsus:/home/michael# hwclock -D
hwclock from util-linux 2.20.1
Using /dev interface to clock.
Last drift adjustment done at 1465279895 seconds after 1969
Last calibration done at 1465279895 seconds after 1969
Hardware clock is on local time
Assuming hardware clock is kept in local time.
Waiting for clock tick...
hwclock: select() to /dev/rtc to wait for clock tick timed out: Success
...synchronization failed

adjtime.config zeigt noch dieselbe Zeitdifferenz an wie gestern Abend (ca 11 Stunden):
47599.159535 1465279895 0.000000
1465279895
LOCAL

Ich fahre das System gleich mal runter und lese dann die Bios-Zeit aus, binmir aber ziemlich sicher dass die auch wieder 70 Stunden in der Zukunft steht.

Ich werde dann mal den von Günter vorgeschlagenen Test machen, und das System paar Stunden ohne Netzwerkverbindung laufen lassen.

beste Grüsse
Michael

[guennid]

Den Windows-Zeit hätte ich auch gerne!!! Um die Diskrepanz ging's doch!!!

[micha81929]

Und was steht in der Datei /var/log/ntp.log ?

Das Logfile /var/log/ntp.log spiegelt die unsinnige Verschiebung des Datums auch wieder:

4 Jun 08:43:55 ntpd[2579]: Deleting interface #6 wlan0, 192.168.178.30#123, interface stats: received=315, sent=335, dropped=0, active_time=5667 secs
4 Jun 08:43:55 ntpd[2579]: 144.76.4.122 interface 192.168.178.30 -> (none)
4 Jun 08:43:55 ntpd[2579]: 46.4.54.78 interface 192.168.178.30 -> (none)
4 Jun 08:43:55 ntpd[2579]: 81.169.163.105 interface 192.168.178.30 -> (none)
4 Jun 08:43:55 ntpd[2579]: 46.4.24.238 interface 192.168.178.30 -> (none)
4 Jun 08:43:55 ntpd[2579]: 129.70.132.33 interface 192.168.178.30 -> (none)
4 Jun 08:43:55 ntpd[2579]: 85.214.7.20 interface 192.168.178.30 -> (none)
4 Jun 08:43:55 ntpd[2579]: peers refreshed
7 Jun 14:57:07 ntpd[2579]: Listen normally on 8 wlan0 192.168.178.30 UDP 123
7 Jun 14:57:07 ntpd[2579]: Listen normally on 9 wlan0 fe80::4a5d:60ff:fe97:c94b UDP 123
7 Jun 14:57:07 ntpd[2579]: peers refreshed
7 Jun 14:57:08 ntpd[2579]: 0.0.0.0 0628 08 no_sys_peer
7 Jun 14:57:20 ntpd[2579]: 0.0.0.0 0617 07 panic_stop -244801 s; set clock manually within 1000 s.
6 Jun 21:56:22 ntpd[2741]: Deferring DNS for ntp1.rz-ip.net 1
6 Jun 21:56:22 ntpd[2741]: Deferring DNS for ntp2.rz-ip.net 1
6 Jun 21:56:22 ntpd[2741]: Deferring DNS for 0.debian.pool.ntp.org 1
6 Jun 21:56:22 ntpd[2741]: Deferring DNS for 1.debian.pool.ntp.org 1
6 Jun 21:56:22 ntpd[2741]: Deferring DNS for 2.debian.pool.ntp.org 1
6 Jun 21:56:22 ntpd[2741]: Deferring DNS for 3.debian.pool.ntp.org 1
6 Jun 21:56:22 ntpd[2741]: 0.0.0.0 c016 06 restart
6 Jun 21:56:22 ntpd[2741]: 0.0.0.0 c012 02 freq_set kernel 0.201 PPM
6 Jun 21:56:22 ntpd[2781]: signal_no_reset: signal 17 had flags 4000000
6 Jun 21:56:24 ntpd[2781]: host name not found: ntp1.rz-ip.net
6 Jun 21:56:24 ntpd[2781]: host name not found: ntp2.rz-ip.net
6 Jun 21:56:24 ntpd[2781]: host name not found: 0.debian.pool.ntp.org
6 Jun 21:56:24 ntpd[2781]: host name not found: 1.debian.pool.ntp.org
6 Jun 21:56:24 ntpd[2781]: host name not found: 2.debian.pool.ntp.org
6 Jun 21:56:24 ntpd[2781]: host name not found: 3.debian.pool.ntp.org
6 Jun 21:56:27 ntpd[2741]: Listen normally on 4 wlan0 192.168.178.30 UDP 123
6 Jun 21:56:27 ntpd[2741]: Listen normally on 5 wlan0 fe80::4a5d:60ff:fe97:c94b UDP 123
6 Jun 21:56:27 ntpd[2741]: peers refreshed
6 Jun 21:56:29 ntpd[2781]: DNS ntp1.rz-ip.net -> 81.169.163.105
6 Jun 21:56:29 ntpd[2781]: DNS ntp2.rz-ip.net -> 85.214.7.20
6 Jun 21:56:29 ntpd[2781]: DNS 0.debian.pool.ntp.org -> 5.200.6.34
6 Jun 21:56:30 ntpd[2781]: DNS 1.debian.pool.ntp.org -> 5.9.122.148
6 Jun 21:56:30 ntpd[2781]: DNS 2.debian.pool.ntp.org -> 212.18.3.18
6 Jun 21:56:30 ntpd[2781]: DNS 3.debian.pool.ntp.org -> 37.120.191.245
6 Jun 21:56:36 ntpd[2741]: 0.0.0.0 c61c 0c clock_step -0.144734 s
6 Jun 21:56:36 ntpd[2741]: 0.0.0.0 c614 04 freq_mode
6 Jun 21:56:37 ntpd[2741]: 0.0.0.0 c618 08 no_sys_peer
6 Jun 22:11:48 ntpd[2741]: 0.0.0.0 c612 02 freq_set kernel -19.196 PPM
6 Jun 22:11:48 ntpd[2741]: 0.0.0.0 c615 05 clock_sync
7 Jun 01:39:42 ntpd[2741]: Deleting interface #5 wlan0, fe80::4a5d:60ff:fe97:c94b#123, interface stats: received=0, sent=0, dropped=0, active_time=13395 secs
7 Jun 01:39:42 ntpd[2741]: Deleting interface #4 wlan0, 192.168.178.30#123, interface stats: received=329, sent=377, dropped=0, active_time=13395 secs
7 Jun 01:39:42 ntpd[2741]: 37.120.191.245 interface 192.168.178.30 -> (none)
7 Jun 01:39:42 ntpd[2741]: 212.18.3.18 interface 192.168.178.30 -> (none)
7 Jun 01:39:42 ntpd[2741]: 5.9.122.148 interface 192.168.178.30 -> (none)
7 Jun 01:39:42 ntpd[2741]: 5.200.6.34 interface 192.168.178.30 -> (none)
7 Jun 01:39:42 ntpd[2741]: 85.214.7.20 interface 192.168.178.30 -> (none)
7 Jun 01:39:42 ntpd[2741]: 81.169.163.105 interface 192.168.178.30 -> (none)
7 Jun 01:39:42 ntpd[2741]: peers refreshed
10 Jun 15:41:15 ntpd[2741]: Listen normally on 6 wlan0 192.168.178.30 UDP 123
10 Jun 15:41:15 ntpd[2741]: Listen normally on 7 wlan0 fe80::4a5d:60ff:fe97:c94b UDP 123
10 Jun 15:41:15 ntpd[2741]: peers refreshed
10 Jun 15:41:16 ntpd[2741]: 0.0.0.0 0618 08 no_sys_peer
10 Jun 15:41:28 ntpd[2741]: 0.0.0.0 0617 07 panic_stop -244802 s; set clock manually within 1000 s.

[guennid]

Für mich ist Schicht im Schacht.

[micha81929]

Den Windows-Zeit hätte ich auch gerne!!! Um die Diskrepanz ging's doch!!!

Wenn ich jetzt Linux runterfahre und aus dem Dual-Boot Windows starte, übernimmt das natürlich die durch Linux veränderte Bios-Zeit

[micha81929]

Aktuelle Bios-Zeit wie befürchtet ist auch 70 Stunden voraus:
und das selbe mit der Windows-Systemzeit

Wenn es jemand nicht glaubt, kann ich auch paar screenshots schicken.

[rendegast]

Die beiden strato-Server haben zwar eine IP, geben ins www aber scheinbar keine Zeit aus:

Code: Alles auswählen

$ /usr/sbin/ntpdate -q ntp1.rz-ip.net
server 81.169.163.105, stratum 0, offset 0.000000, delay 0.00000
 7 Jun 21:17:53 ntpdate[15304]: no server suitable for synchronization found

$ /usr/sbin/ntpdate -q ntp2.rz-ip.net
server 85.214.7.20, stratum 0, offset 0.000000, delay 0.00000
 7 Jun 21:18:12 ntpdate[15309]: no server suitable for synchronization found

$ /usr/sbin/ntpdate -q 0.debian.pool.ntp.org
server 78.47.148.174, stratum 2, offset 0.000517, delay 0.05644
server 46.4.24.238, stratum 2, offset 0.000241, delay 0.05646
server 148.251.84.200, stratum 3, offset 0.000416, delay 0.05646
server 129.70.132.33, stratum 2, offset 0.005478, delay 0.04118
 7 Jun 21:18:39 ntpdate[15315]: adjust time server 129.70.132.33 offset 0.005478 sec



$ /usr/sbin/ntpdate -q de.pool.ntp.org
server 78.46.107.140, stratum 2, offset 0.000425, delay 0.05579
server 85.25.138.48, stratum 2, offset -0.003171, delay 0.05278
server 91.237.88.67, stratum 2, offset 0.003799, delay 0.04756
server 134.34.3.19, stratum 1, offset 0.004211, delay 0.04645
 7 Jun 21:29:30 ntpdate[15457]: adjust time server 134.34.3.19 offset 0.004211 sec

Windows hat im Default eine Begrenzung der Korrektur um maximal 57600s / 16h
(MaxPosPhaseCorrection,MaxNegPhaseCorrection).
Das kann auf 0xffffffff gesetzt werden, entspräche "unbegrenzt".
Ohne diese Änderung sollte Windows also auch keine Korrektur um 70h vornehmen.

[micha81929]

Den Windows-Zeit hätte ich auch gerne!!! Um die Diskrepanz ging's doch!!!

Wenn ich den Sachverhalt nicht ganz klar beschrieben haben sollte: Es gibt keine Diskrepanz zwischen Linux- und Windows-Systemzeit (bzw. Bios-Zeit). Aber sobald Linux Debian anfängt, seine Systemzeit zu verändern (immer in Richtung Zukunft), überschreibt es damit auch die Bios-Zeit wodurch dann Windows (beim nächstbesten Windows-Booten ebenfall diese fehlerhafte Zeit übernimmt).
Wie gesagt passiert soetwas nicht, wenn ich Windows boote. Ich glaube auch nicht, dass die Bios Uhr fehlerhaft ist, weil die völlig korrekt weiterläuft wenn der Rechner mehrere Tage lang runtergefahren bleibt.

[micha81929]

Die beiden strato-Server haben zwar eine IP, geben ins www aber scheinbar keine Zeit aus:

Ich habe noch zusätzliche Listen von NTP Servern,die ich reinschreiben könnte. Ich bezweifle aber, dass das das beschriebene Problem löst, weil ich ja vorher ohne NTP auch schon diese Zeitverschiebung hatte.

Windows hat im Default eine Begrenzung der Korrektur um maximal 57600s / 16h
(MaxPosPhaseCorrection,MaxNegPhaseCorrection).
Das kann auf 0xffffffff gesetzt werden, entspräche "unbegrenzt".
Ohne diese Änderung sollte Windows also auch keine Korrektur um 70h vornehmen.

Meinst Du wirklich "Windows", oder "Linux" ? Das würde erklären, wieso hwclock jetzt keine Korrektur mehr macht. Das würde implizieren, dass bei 70 Stunden aufgelaufener Zeitverschiebung dann Schluss ist. Wäre ja wenigstens eine gute NAchricht. Mal schauen.

[micha81929]

Aktuelle Bios-Zeit wie befürchtet ist auch 70 Stunden voraus:
und das selbe mit der Windows-Systemzeit

Wenn es jemand nicht glaubt, kann ich auch paar screenshots schicken.

Bios Zeit https://www.dropbox.com/s/v3e3vv4os853d ... 3.jpg?dl=0
Windowszeit https://www.dropbox.com/s/efcygr2a0pk5e ... 1.jpg?dl=0

[spiralnebelverdreher]

Die beiden strato-Server haben zwar eine IP, geben ins www aber scheinbar keine Zeit aus:

Ich habe noch zusätzliche Listen von NTP Servern,die ich reinschreiben könnte. Ich bezweifle aber, dass das das beschriebene Problem löst, weil ich ja vorher ohne NTP auch schon diese Zeitverschiebung hatte.

Zusätzliche Server nutzen dir hier nichts. Dein Problem ist die große Abweichung der HW-Clock von der ntp-Zeit, die den ntp-Daemon daran hindert sein nützliches Werk zu verrichten.
Ich würde die beiden Stratoserver auskommentieren und den Rest lassen wie es ist. In diesem Link https://wiki.hetzner.de/index.php/Uhrze ... en_mit_NTP ist beschrieben, wie man die HW-Zeit an die ntp-Zeit angleicht, auch wenn die Differenz zwischen beiden sehr groß ist. Probier das mal aus.

In deinem Logfile steht ja auch, dass der ntp Daemon die Arbeit einstellt, weil ihm die Zeitdifferenz zu groß ist:

Code: Alles auswählen

 panic_stop -244802 s; set clock manually within 1000 s.

Oder alternativ erstmals die Zeit von Hand setzen (mit weniger als 1000s Abweichung) und dann den Daemon neu starten: /etc/init.d/ntp restart. In den Logfiles sollte dann nach einer Minute oder so etwas in dieser Art stehen:

Code: Alles auswählen

 7 Jun 22:18:26 ntpd[4445]: 0.0.0.0 c016 06 restart
 7 Jun 22:18:26 ntpd[4445]: 0.0.0.0 c012 02 freq_set kernel -7.744 PPM
 7 Jun 22:18:33 ntpd[4445]: 0.0.0.0 c615 05 clock_sync