Probleme mit lokaler Zeit

[Otto123]

Hallo Werner,

ok der ntp Dienst macht das nicht direkt. Habe ich falsch gesehen.
Aber das System muss doch selbständig die RTC mal setzen, ohne das der user das tut? Sonst macht es doch keinen Sinn und beim booten ist wieder alles durcheinander.
Bei Linux kenn ich mich eben zu wenig aus. Windows macht das mit der Uhr und dem ntp genauso, aber wenn die RTC gar nicht stimmte und ich boote ein Windows System welches sich selbstständig mit einem ntp Server synchronisiert, dann stimmt nach einem Neustart auch die RTC.

Gruß Otto

[Wernieman]

Das liegt daran, das sich Windows den Zeitunterschied zwischen HTC und System merkt. Beim booten also den Fehler automatisch korrigiert.
Linxu fast die HTC nur lesen an, es sei denn
- Du machst es manuell
- es wurde eingestellt, das er beim runterfahren die Zeit angleicht

Hatte mal (vor 14 Jahren) einen Kleinstserver auf Arbeit, dessen HTC scheinbar defekt war. Am tage eine Zeitdifferenz von 10 Minuten aufgebaut. Da ntp nicht läuft, wenn der Zeitunterschied größer 1h, haben wir bei dem Seerver per cronjob ein mal am Tag die HTC Uhrzeit hart gesetzt. So das bei einem eventuellen reboot die zeit stimmt ... hat fantastisch funktioniert(und es Geld für einen neuen Server gespart ;o) )

[Tobias]

Hi Wernieman,

danke für die vielen Infos. HIer mal ein paar Auschnitte nach Infos die du wolltest
http://www.vdr-portal.de/board60-linux/board14-betriebssystem/board96-yavdr/116620-0-5-vdr-wacht-nicht-zur-geplanten-aufnahme-aus-dem-s3-auf/
http://www.vdr-portal.de/board16-video-disk-recorder/board99-distributionen/board96-yavdr/p1111792-0-5-vor-und-nachlaufzeit-bei-timern/#post1111792
http://www.vdr-wiki.de/wiki/index.php/ACPI_Wakeup

[Wernieman]

D.h.ö Du hast ein Multiboot-System ...das Erklärt den Grund

[Tobias]

Nö, ich habe kein Multiboot. Bei mir im Haushalt gibt es nur einen Windows Rechner. Der ist für die jährliche Steuererklärung. Ansonsten hab ich nur reine Linuxe.

Jedenfalls hatte ich auf meinem YaVDR Probleme mit den automatisierten Einschalten. Da kam der Hinweis mit dem UTC. Und damit ich nicht bei verschiedenen Rechnern umdenken muss, mache ich es überall gleich...

[Otto123]

Nö, ich habe kein Multiboot. Bei mir im Haushalt gibt es nur einen Windows Rechner. Der ist für die jährliche Steuererklärung. Ansonsten hab ich nur reine Linuxe.

Jedenfalls hatte ich auf meinem YaVDR Probleme mit den automatisierten Einschalten. Da kam der Hinweis mit dem UTC. Und damit ich nicht bei verschiedenen Rechnern umdenken muss, mache ich es überall gleich...

Hi Tobias,

ich glaube das hält "fit" ist aber eigentlich unnütz. Ich sehe keinen Grund warum wegen dem ACPI Wakeup die RTC auf UTC laufen sollte. Aber sicher habe ich es aus den Links nicht verstanden - aber in den Links geht es doch immer um Multiboot? Und da ist es in der Tat ein zusätzliches Problem

Wichtig ist eigentlich, das "Alle" wissen, welche Uhr wie läuft, damit es in Summe klappt wie angedacht.

Als einziges was mir jetzt einfällt ist die Problematik Umschalten von Sommer auf Winterzeit und umgekehrt. Da weiß im BIOS keiner was davon und ACPI wakeup passiert zur falschen Zeit. Aber selbst das kann man doch nur umgehen wenn die BIOS Uhr die Zeitzone und deren Regeln kennen würde.
Gedankenscenario:
RTC auf UTC
Film-Timer morgen um 11:00 , heute Winterzeit, Timer wird auf UTC 10:00 gesetzt damit die Kiste um 10:00 UTC (11:00 CET) aufwacht.
Morgen ist dann "plötzlich" Sommerzeit, der Film kommt immer noch um 11:00, ACPI weckt um  10:00 UTC -> 12:00  CET der Filmstart ist schon vorbei.
RTC auf CET
Film-Timer morgen um 11:00 , heute Winterzeit, Timer wird auf UTC 11:00 gesetzt damit die Kiste um 11:00 UTC(=CET) aufwacht.
Morgen ist dann "plötzlich" Sommerzeit, der Film kommt immer noch um 11:00, ACPI weckt um  11:00 UTC -> 12:00  CET der Filmstart ist schon vorbei.

Ok das ganze würde funktioneren, wenn der ACPI Timer "Setzer" beim setzen die Umrechnung Zeitzone (mit Sommerzeit) -> UTC kennt, würde aber auch funktionieren, wenn er nur weiß das er auf Sommerzeit umrechnen muss.

Gruß Otto

[Wernieman]

Ich würde das Problem mit WOL umgehen .. der Server startet alle Clients (bzw. eigentlich sogar mit Hilfe einer schaltbaren Steckdose um nicht zu vernachlässigen Ruhestrom zu umgehen)

Habe bei meinen (laaange her) ACPI einschaltversuchen auf Consumer Hardware so negative Erfahrungen gemacht, das ich es (bis heute) nicht einsetzen würde ...

[Otto123]

Ich habe mal für mich noch ein bisschen recherchiert und ziehe für mich folgende Erkenntnis:
Linux Systeme sollen wohl per default mit RTC=UTC laufen. Das würde also (per default) immer zu Befindlichkeiten in Multiboot Systemen mit Windows führen.
Das automatische stellen der RTC in Linux ist eventuell so vielfältig wie die Linuxe dieser Welt -> von "gar nicht" bis "alle 11 Minuten" (oder so)
Offenbar ist das Stellen beim shutdown verbreitet. Bei debian/systemd über hwclock-save.service

Die Systeme (z.B. VDR Systeme) die ACPI Timer benutzen, schreiben die im shutdownscript. Die wissen also, ob bis zum nächsten Timer die Uhr auf Sommerzeit geht. 

Gruß Otto

[Tobias]

Hi,
aus irgendwelchen Gründen passt die zeit bei mir schon wieder nicht.
Ich habe es jetzt schon so hinbekommen, das ein hwclock --debug die korrekte UTC und korrekte LOkalzeit ausgibt.
Blöderweise gibt ein "date" aber immer noch eine falsche zeit aus.

WOher kommt die Diskrepanz zwischen der lokalzeit die "hwclock" ausgibt und der ZEit die "Date" ausgibt?

"So 09 Apr 2017 08:04:07 CEST"  ist nicht(!) "So 9. Apr 10:43:36 CEST 2017"

Code Auswählen Erweitern

root@www:~# hwclock --debug
hwclock from util-linux 2.20.1
Using /dev interface to clock.
Last drift adjustment done at 1491715775 seconds after 1969
Last calibration done at 1491715775 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2017/04/09 06:04:07
Hw clock time : 2017/04/09 06:04:07 = 1491717847 seconds since 1969
So 09 Apr 2017 08:04:07 CEST  -1.308148 seconds
root@www:~#
root@www:~# date
So 9. Apr 10:43:36 CEST 2017
root@www:~#


in /etc/adjtime steht folgendes, was bedeutet das?

Code Auswählen Erweitern

-209.427339 1491715775 0.000000
1491715775
UTC


[Otto123]

Moin,

das würde bedeuten deine hwclock läuft richtig und deine Systemzeit läuft falsch?

Läuft denn ein ntp bei Dir?

Hier ist das mit /etc/adjtime ganz gut beschrieben https://wiki.archlinux.org/index.php/time

Gruß Otto

[Wernieman]

Die Systemzeit (date) wird beim booten auf die Hardwarezeit (hwclock) gesetzt. Anschließend übernimmt das System selbständig die Zeitrechnung, d.h. die hardwarezeit wird nicht berücksichtigt, es sei denn es läuft ein ntpd, der auch die Lokale Quelle als Zeitquelle hat (am besten mit hohem stratum)

Konfiguration des ntp siehe anleitungen im Netz ... gibt genug davon (beinahe zu viele) ..

BTW:
beim Vergleich der Zeiten hwclock/date am besten nicht die Kommandos per Hand nacheinander Ausführen sonder "am Stück" zur Bash schicken. So kann ma besser vergleichen:

Code Auswählen Erweitern

hwclock; date

[Tobias]

Bei mir läuft ein openNTP.
Allerdings frage ich mich dann, warum meine Hardwarezeit teilweise so daneben geht

[Wernieman]

Wie alt ist das Mainboard? Batterie defekt?

was sagt denn bei Dir:

Code Auswählen Erweitern

ntpq -p

[Otto123]

Hallo Tobias,

ich hatte verstanden Deinen Hardwarezeit war richtig und deine Systemzeit falsch - hab ich das völlig falsch gelesen?

Gruß Otto

[Tobias]

Ich habe es jetzt mal versucht so zu lösen, das ein cron Job per ntpdate die lokale zeit updatet und dann gleich danach die Hardware Uhr stellt. Mal schauen wie es nach dem nächsten Reboot ausschaut

Ist übrigens ein cubietruck, 2 Jahre alt

Gesendet von meinem Leap mit Tapatalk