Hi,
ich sehe gerade den Wald vor lauter bäumen nicht. Meine lokale Zeit steht auf UTC, anstatt auf lokal. Und ich bekomme es nicht hin.
HIer mal ein paar ausgaben
root@www:~# hwclock --debug
hwclock from util-linux 2.20.1
Using /dev interface to clock.
Last drift adjustment done at 1486140106 seconds after 1969
Last calibration done at 1486140106 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/02/03 16:50:50
Hw clock time : 2017/02/03 16:50:50 = 1486140650 seconds since 1969
Fr 03 Feb 2017 17:50:50 CET -1.338605 seconds
root@www:~# date
Fr 3. Feb 17:50:52 CET 2017
root@www:~#
Wiw mach ich das am schlauesten?
was willst Du denn genau tun? die hwclock auf local umstellen oder die Systemzeit der Hardware? Das muss nicht zwingend das gleiche sein.
root@fhem-demo:/home/udo# hwclock --systohc
root@fhem-demo:/home/udo# hwclock -r
Fr 03 Feb 2017 16:51:15 CET -0.710666 seconds
root@fhem-demo:/home/udo# date
Fr 3. Feb 16:51:27 CET 2017
root@fhem-demo:/home/udo# hwclock --debug
hwclock from util-linux 2.25.2
Using the /dev interface to the clock.
Last drift adjustment done at 1486137071 seconds after 1969
Last calibration done at 1486137071 seconds after 1969
Hardware clock is on UTC time
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
/dev/rtc does not have interrupt functions. Waiting in loop for time from /dev/rtc to change
...got clock tick
Time read from Hardware Clock: 2017/02/03 15:51:55
Hw clock time : 2017/02/03 15:51:55 = 1486137115 seconds since 1969
Fr 03 Feb 2017 16:51:55 CET -0.257387 seconds
Beser übrigens ist es, beide Befehle "im gleichen Schuß" loszusenden:
hwclock; date
So kann man am besten "vergleichen".
Und wegen Uhrzeit ... auf was steht bei Dir die lokale Uhrzeit?
ls -lha /etc/localtime
Mehr Tips kann ich Dir (momentan) nicht geben, da ich Deine Distri nicht weiß ....
So siehts aus, ist ein Cubietruck. Also ein Debian System
root@www:~# hwclock;date
Fr 03 Feb 2017 18:46:07 CET -1.242317 seconds
Fr 3. Feb 18:46:06 CET 2017
root@www:~# ls -lha /etc/localtime
-rw-r--r-- 1 root root 2,3K Dez 21 14:04 /etc/localtime
root@www:~#
Was will ich? HWClock soll auf UTC stehen. Systemzeit auf lokaler Zeit. Irgendwie hatte ich das mal auch hinbekommen, aber bei inem Reboot ist imemr alles wieder durcheinander :(
Hi Tobias,
aber in deinem ersten Post stimmt doch alles?
Hardware clock is on UTC time
...
Time read from Hardware Clock: 2017/02/03 16:50:50
Hw clock time : 2017/02/03 16:50:50 = 1486140650 seconds since 1969
...
root@www:~# date
Fr 3. Feb 17:50:52 CET 2017
Zeitzone ist CET Central Europe Time.
???
sudo hwclock -wu setzt die hwclock auf UTC
Gruß Otto
ich werd hier noch zum Tier ... :(
schaut mal in die Abfolge, ich kann machen was ich will, die Systemzeit verändert sich nicht....
root@www:~# hwclock;date
Fr 03 Feb 2017 18:46:15 CET -1.176496 seconds
Fr 3. Feb 20:56:44 CET 2017
root@www:~# hwclock -su
root@www:~# hwclock;date
Fr 03 Feb 2017 18:46:32 CET -1.809195 seconds
Fr 3. Feb 20:57:01 CET 2017
root@www:~# dpkg-reconfigure tzdata
Current default time zone: 'Europe/Berlin'
Local time is now: Fri Feb 3 20:58:31 CET 2017.
Universal Time is now: Fri Feb 3 19:58:31 UTC 2017.
root@www:~# hwclock;date
Fr 03 Feb 2017 18:48:20 CET -1.726254 seconds
Fr 3. Feb 20:58:49 CET 2017
root@www:~#
Tipp zur Umstellung der Zeit (s.o.) befolgt?
Aber warum willst Du die HW-Clock und die Systemclock unterschiedlich behandeln? Weil es geht??
Mir erschließt sich der Sinn nicht ..... würde beide auf die gleiche Zeit laufen lassen (hat der Cubi überhaupt eine echte Echtzeituhr?)
Hat übrigens noch einen Vorteil:
Wenn Du einen npd-Client laufen lässt, guckt der auch, ob die Ziel Zeit und die HW-Clock einen Unterschied >Xh (auch glaube X=1) hat .. wenn ja, aktuallisiert er nicht (mehr). Und ntp ist so Systemsparend, dass sollte man sich heute auf jedem 24/7 (und auf den anderen auch) leisten ....
@ Tobias -> -wu nicht -su
Upps... :D
root@bananapro ~ # hwclock;date
Fr 01 Jan 2010 01:00:00 CET -10.011758 seconds
Fr 3. Feb 21:28:49 CET 2017
geht nur 10 sec falsch ;D ;D ;D
Ich hab das Problem immer noch nicht verstanden.
Zitat von: betateilchen am 03 Februar 2017, 22:24:54
Ich hab das Problem immer noch nicht verstanden.
Ich denke Tobias will, dass die hwclock (RTC) mit UTC läuft anstatt mit CET.
Auf meiner NAS konnte ich das testweise so einrichten, überlebt auch den Neustart.
sudo hwclock --debug
hwclock from util-linux 2.20.1
Using /dev interface to clock.
Last drift adjustment done at 1486142037 seconds after 1969
Last calibration done at 1486142037 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/02/03 21:44:05
Hw clock time : 2017/02/03 21:44:05 = 1486158245 seconds since 1969
Fr 03 Feb 2017 22:44:05 CET -0.599786 seconds
Wofür das gut ist verstehe ich auch nicht.
Ich glaube aber nicht, dass das wirklich Sinn macht. Aber man kann es so machen. Ich weiß gar nicht ob alle im System damit klar kommen.
Gruß Otto
Also ich kenne das so das die HW-clock auf UTC laufen soll und die Systemzeit auf Lokal. Zuminstest muss das bei meinem Yavdr so sein da es sonst probleme gibt.
Also mache ich das auch so auf all meinen anderen REchnern...
Habs jetzt irgendwie hinbekommen:
root@www:~# hwclock --set --utc --date="02/04/2017 20:06:00"
root@www:~# hwclock --debug
hwclock from util-linux 2.20.1
Using /dev interface to clock.
Last drift adjustment done at 1486234800 seconds after 1969
Last calibration done at 1486234800 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/02/04 19:06:24
Hw clock time : 2017/02/04 19:06:24 = 1486235184 seconds since 1969
Sa 04 Feb 2017 20:06:24 CET -1.619909 seconds
root@www:~# hwclock;date
Sa 04 Feb 2017 20:06:54 CET -1.999576 seconds
Sa 4. Feb 20:06:52 CET 2017
root@www:~#
Eigentlich ist die RTC nur eine Uhr. Die hat keine Zeitzone, die läuft einfach und zählt die Sekunden.
Gesetzt wird die die RTC im übrigen auch durch den ntp Dienst, ein hwclock --set ist normalerweise unnötig.
Das laufende System Linux, Windows egal, geht davon aus, das die RTC in einer bestimmten Zeitzone gestellt ist.
Windows geht davon aus, das es die System lokale Zeitzone ist, also bei uns CET
Linux geht eigentlich auch davon aus, zumindest die Linuxe die ich momentan im Zugriff habe.
Macht man jetzt Multiboot (mehrere System auf einer Büchse) ensteht das Problem: Alle sollten das Gleiche "denken"! Sonst gibt es immer beim booten Kauderwelch.
Bestimmen tut es der Admin 8) also Du Tobias, wenn Du sagst Du machst es auf allen Rechnern das ist das so.
Ich denke ein Problem ist es wirklich nur wenn unterschiedliche Systeme (oder Dienste) auf die RTC zugreifen und unterschiedlicher Meinung sind.
Man kann Linux und Windows so konfigurieren, das sie davon ausgehen, das RTC in UTC gestellt ist.
hwclock -wu
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal
Aber unter Linux gibt es da bestimmt soviel Varianten das einzustellen wie es Linuxe gibt :-X
Gruß Otto
ZitatGesetzt wird die die RTC im übrigen auch durch den ntp Dienst, ein hwclock --set ist normalerweise unnötig.
Sorry, das stimmt so definitiv nicht (unter Linux).
der ntp stellt die Softwareuhr. Nicht Hart, sondern durch schneller/langsamer laufen lassen. Welcher Stand die HWClock hat, ist dem System egal. Die Uhrzeit wird nur beim Booten von der HWClock genommen (und wenn man es explizit befiehlt, wie z.B: hwclock --hctosys). Entsprechend stellt das System auch nicht die HWClock (auch hier: es sei denn man befielt es, z.B. hwclock --systohc)
@Tobias:
Woher kennst Du es?
Meine Systeme, privat und beruflich, laufen Softqware/Hardwareseitig in der gleichen Zeitzohne. Vor allem auch, um eventuelle iritationen beim Booten zu vermeiden. Und da waren auch "Farmen von Serverzahl >500" dabei. Insofern wüste ich gerne, woher Du diese Meinung hat (bitte nicht angegriffen fühlen). Bilde mich gerne weiter ...
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
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) )
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
D.h.ö Du hast ein Multiboot-System ...das Erklärt den Grund
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...
Zitat von: Tobias am 06 Februar 2017, 11:58:31
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
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 ...
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. 8)
Gruß Otto
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"
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?
-209.427339 1491715775 0.000000
1491715775
UTC
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
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:
hwclock; date
Bei mir läuft ein openNTP.
Allerdings frage ich mich dann, warum meine Hardwarezeit teilweise so daneben geht :(
Wie alt ist das Mainboard? Batterie defekt?
was sagt denn bei Dir:
ntpq -p
Hallo Tobias,
ich hatte verstanden Deinen Hardwarezeit war richtig und deine Systemzeit falsch - hab ich das völlig falsch gelesen?
Gruß Otto
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
cron Job per ntpdate
s.o. ..
schon mal was von ntpd gehört? Unix (Linux) mag es überhaupt nicht, wenn die zeit sprünge macht. Übrigens Windows in einer ActiveDirektory Umgebung auch nicht ,,,
Hatte ich vor openntpd am laufen. Hatte meine Zeit aber nicht interessiert, obwohl die Konfiguration imho sauber war :(
Gesendet von meinem Leap mit Tapatalk
Wenn ntp läuft, sollte man mit "ntpq -p" auch gucken, ob sie wirklich aktuell ist.
Wie schon gesagt, Unix (linux) mag es nicht, wenn die Zeit sprünge macht ...