Ärger mit Systemzeit

    Hi,


    ich habe momentan Probleme mit der aktuellen Systemzeit von meinem VDR. Irgendwie wird /etc/adjtime verhunzt. Da steht dann aktuell


    83513.747552 1191797178 0.000000
    1191794963
    LOCAL


    drin. Das führt dazu, daß beim Booten die Zeit um Stunden zurück und dann von ntp wieder korrigiert wird. Im Log steht folgendes:


    Oct 8 00:09:04 very-new-darkstar syslog-ng[3435]: syslog-ng version 1.6.11 going down
    Oct 8 00:46:26 very-new-darkstar syslog-ng[3445]: syslog-ng version 1.6.11 starting
    ...
    Oct 8 00:46:27 very-new-darkstar vdr: [3561] VDR version 1.5.9 started
    ...
    Oct 8 18:35:06 very-new-darkstar ntpdate[3586]: step time server 87.139.126.233 offset 64111.589162 sec
    Oct 8 18:35:06 very-new-darkstar ntpd[3852]: ntpd 4.2.2p4@1.1585-o Sat Nov 25 18:52:42 UTC 2006 (1)
    Oct 8 18:35:06 very-new-darkstar ntpd[3853]: precision = 2.000 usec
    Oct 8 18:35:06 very-new-darkstar ntpd[3853]: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16
    Oct 8 18:35:06 very-new-darkstar ntpd[3853]: Listening on interface wildcard, 0.0.0.0#123 Disabled
    Oct 8 18:35:06 very-new-darkstar ntpd[3853]: Listening on interface wildcard, ::#123 Disabled
    Oct 8 18:35:06 very-new-darkstar ntpd[3853]: Listening on interface lo, ::1#123 Enabled
    Oct 8 18:35:06 very-new-darkstar ntpd[3853]: Listening on interface wlan0, fe80::211:f6ff:fe7f:d4a3#123 Enabled
    Oct 8 18:35:06 very-new-darkstar ntpd[3853]: Listening on interface lo, 127.0.0.1#123 Enabled
    Oct 8 18:35:06 very-new-darkstar ntpd[3853]: Listening on interface wlan0, 192.168.2.6#123 Enabled
    Oct 8 18:35:06 very-new-darkstar ntpd[3853]: kernel time sync status 0040
    Oct 8 18:35:06 very-new-darkstar ntpd[3853]: frequency initialized -113.271 PPM from /var/lib/ntp/drift/ntp.drift


    Ich habe die BIOS-Zeit vor dem Starten kontrolliert, die ist korrekt. Wenn ich adjtime lösche, ist alles für ein paar Tage OK. Ich benutze Suse 10.2 mit den Kernels 2.6.22.9 bzw. 2.6.23-rc9. Wie wird adjtime eigentlich erzeugt bzw. beim Booten berücksichtigt? Ich könnte adjtime beim Booten oder Runterfahren immer löschen, aber das beseitigt das Problem nicht wirklich.


    Hat jemand eine Idee, was los sein könnte?


    Gruß
    e9hack

    Hallo,


    das Problem habe ich auch schon seit langem (Suse 10.0). Ich lösche immer wieder mal die adjtime. Eine wirkliche Lösung ist das aber, wie Du schon sagtest, nicht.


    Vielleicht hat noch jemand eine Zündende Idee...


    Mitch

    i3-2120T - Suse 13.1 - VDR 2.0.5 - FF 2.3
    i3-2120T - Suse 12.1 - VDR 1.6.0 - FF 2.3
    Sempron 2800+ - Suse 11.2 - VDR 1.6.0 - FF 2.3
    Duron 900 - Suse 8.2 - VDR 1.2.6 - FF 1.3

    Das hier müsste helfen:

    1: /etc/init.d/ntp stop
    2: rm /etc/adjtime
    3: mit yast deinen Rechner auf utc anstatt localtime umstellen. Dann funktiniert auch
    die Sommer/Winterzeitumstellung von alleine.
    4: ntpdate 0.pool.ntp.org
    um die Uhr richtig zu stellen. Ginge auch mit yast oder date.
    5: Mit
    hwclock --systohc --utc
    die jetzt richtige Zeit ins CMOS schreiben.
    6: /etc/int.d/ntp start


    Das ändert die Zeit nur auf UTC. UTC ist keine Option, da auch noch ein W2K auf der Kiste laufen muß. Ich glaube auch nicht, das es ein Localtime-Problem ist.


    Wenn ich so an meine letzten Änderungen denke, hat alles mit der Umstellung von Suse 10.2 32Bit auf Suse 10.2 64Bit angefangen.


    Ich habe um die interessanten Einträge in /etc/init.d/boot.clock 'logger'-Einträge gepflanzt. Mal sehen, ob ich rausfinde woran es liegt. Wenn ich das Problem nicht lösen kann, schalte ich den adjtime Mechanismus komplett ab.


    Gruß
    e9hack

    Zitat

    Original von FireFly
    Wenn Du das UTC weglässt sollte es aber das Problem lösen (hat es bei mir auch mal). Vermutlich hat irgendwas mal die Uhr umgestellt, so daß ein (zu) großer Korrekturfaktor ermittelt wurde.


    Wenn ich die adjtime einmalig lösche, ist das Problem schon beseitigt. Nur würde ich gern wissen, wie die 'schräge' Drift in die adjtime reinkommt. Gelegentlich muß irgendwas beim Runter- und wieder Hochfahren in die Hose gehen.


    Gruß
    e9hack

    So wie es aussieht wird ein ungültiger Wert in die adjtime eingetragen, vermutlich durch Zeitmarken die clock -au dort einträgt.


    Eigentlich brauchst du die Datei wohl nicht, die korrigiert nur den Gangfehler der Bios-Uhr um die erste Zahl in sekunden. In deinem Falle war die Uhrzeit zum time stamp "1191797178" um -83513.747552 sec falsch. Das sind immerhin 19h und nochwas.


    Ich würd auf den Quatsch verzichten und einmal beim Systemstart netdate oder ntpdate ausführen.

    Zitat

    Original von wirbel
    Ich würd auf den Quatsch verzichten und einmal beim Systemstart netdate oder ntpdate ausführen.


    Das sehe ich auch so. Ich möchte aber schon wissen, warum die Kiste 1 Jahr problemlos lief und jetzt rumzickt.


    Gruß
    e9hack

    Vielleicht hat der eingestellte time server ab & zu Datenmüll an deine Kiste geschickt..

    Zitat

    Original von wirbel
    Vielleicht hat der eingestellte time server ab & zu Datenmüll an deine Kiste geschickt..


    Das letzte Runterfahren stimmt eigentlich:


    Oct 8 00:09:04 very-new-darkstar syslog-ng[3435]: syslog-ng version 1.6.11 going down


    Beim Hochfahren hat irgend etwas nicht gestimmt:


    Oct 8 00:46:26 very-new-darkstar syslog-ng[3445]: syslog-ng version 1.6.11 starting


    NTP hat ja die Zeit wieder korrigiert:


    Oct 8 18:35:06 very-new-darkstar ntpdate[3586]: step time server 87.139.126.233 offset 64111.589162 sec


    Gruß
    e9hack

    Die Bios Batterie ist nicht zufällig alle?


    Dann würde es Sinn machen: Im Bios steht eine beliebig falsche Zeit, ntp korrigiert und setzt den gefundenen offset in adjtime. Die 19h entsprechen dem Eintrag den du oben gepostet hast.

    Zitat

    Original von wirbel
    Die Bios Batterie ist nicht zufällig alle?


    Ich habe gestern den VDR aufgeschraubt und wollte die Batterie wechseln. Die hatte noch 3,xxV.


    Zitat


    Dann würde es Sinn machen: Im Bios steht eine beliebig falsche Zeit, ntp korrigiert und setzt den gefundenen offset in adjtime. Die 19h entsprechen dem Eintrag den du oben gepostet hast.


    Wegen meiner Aktion von Gestern hat noch die (Funk-)Tastatur im Wohnzimmer gelegen. Ich habe beim Booten ins BIOS geschaut: die Uhr lief korrekt.


    Gruß
    e9hack

    Wenn die Batterie alle wäre, dann hätte er aber auch jegliche Einstellung im BIOS verloren.


    Weiterhin..wenn die Kiste perm. am Strom hängt und ein ATX netzteil hat, sollte es damit keinen Stress geben.

    MAIN: La Scala SST-LC04 Gehäuse / Asus P5N7A-VM / Intel E7500 / YaVDR 0.1 / TT-DVB-S2 / IR-Einschalter Atric / Wakeup-On-Call


    ICH: Bin Microsoft, Cisco, VMware und NetApp zertifiziert


    Dann muss die Ursache beim Start des Rechners zu suchen sein. Außerdem würde dein vdr ja mit leerer Batterie auch diverse Timer auslassen..

    Zitat

    Original von wirbel
    Die Bios Batterie ist nicht zufällig alle?


    Dann würde es Sinn machen: Im Bios steht eine beliebig falsche Zeit, ntp korrigiert und setzt den gefundenen offset in adjtime. Die 19h entsprechen dem Eintrag den du oben gepostet hast.


    ??


    Zitat

    Original von e9hack
    Ich habe die BIOS-Zeit vor dem Starten kontrolliert, die ist korrekt.
    e9hack


    Gruß Fr@nk

    Zitat

    Original von peda
    Weiterhin..wenn die Kiste perm. am Strom hängt und ein ATX netzteil hat, sollte es damit keinen Stress geben.


    Die Kiste ist vom Netz getrennt und wird über ein Solid-State-Relais eingeschaltet. Ich benutze eine externe Wakeup-Box, die am Infrarot-Empfänger mitlauscht und per serieller Schnittstelle auf den nächsten Timer programmiert wird.


    Gruß
    e9hack

    Ich habe in die boot.clock ein paar 'echo's mehr eingetragen. Für ein Shutdown/Reboot bekomme ich folgenden Log:


    Code
    10/08/07 21:49:03 =========================
10/08/07 21:49:03 boot.clock: Set Hardware Clock to the current System Time
10/08/07 21:49:05 boot.clock: after /sbin/hwclock --systohc --localtime
10/08/07 23:52:47 =========================
10/08/07 23:52:47 boot.clock: Setting up the hardware clock
10/08/07 23:52:47 boot.clock: before /sbin/hwclock --adjust --localtime
10/08/07 23:52:48 boot.clock: after /sbin/hwclock --adjust --localtime
10/08/07 23:52:48 boot.clock: before /sbin/hwclock --hctosys --localtime
10/08/07 21:52:50 boot.clock: after /sbin/hwclock --hctosys --localtime


    Ich hoffe, das ich den Aufruf finde, der meine Systemzeit verorgelt.


    Gruß
    e9hack

    Bei Umstieg auf neuere Kernel musste ich mal '/sbin/hwclock' immer zusaetzlich mit Option '--directisa' starten. Da der Zugriff ueber das /dev/rtc device nicht mehr funktioniert hat.


    Ich habe aber nicht genau ueberlegt, ob deine Fehlersymptome zu diesem Fix passen koennten :)

    cd /etc/init.d
    mv boot.clock boot2.clock


    oder in etwas anderes umbenennen...... dann wird beim starten das script boot.clock halt nicht gefunden......... und eure Uhrzeit bleibt.... aber denkt dran... wenn cron dann durchdreht wars ich nicht

    SD:576i
    VDR: Scovery Xs, P3 1GHz, 128MB, PATA 120GB Samsung, Slim DVD+/-RW,1x DVB-S_FF1.6,1x SkyStar 2.6D,Rebach RGB 576i an,21" Philips CRT
    HD:720p/1080i/1080p
    FULL HDTV & DVB-S2:SONY PS3-60GB + Kathrein UFS 910 per HDMI Pioneer 5000EX

    Zitat

    Original von vatheuer
    cd /etc/init.d
    mv boot.clock boot2.clock


    oder in etwas anderes umbenennen...... dann wird beim starten das script boot.clock halt nicht gefunden......... und eure Uhrzeit bleibt.... aber denkt dran... wenn cron dann durchdreht wars ich nicht


    Das Problem ist seit 4 Monaten nicht mehr aufgetreten. Eigentlich wollte ich auch die Ursache und nicht das Ergebnis beseitigen.


    Gruß
    e9hack

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!

Benutzerkonto erstellen Anmelden