Korrekte Uhrzeit in docker containern

[alex7]

Hallo zusammen,

 

ich bin noch relativ neu beim System unRaid und auch allgemein bei Linux. Mein Problem ist aber zur Zeit, dass ich unter anderem bei Vaultwarden und CloudberryBackup Probleme mit der richtigen Uhrzeit habe. Vielleicht ist es auch nur ein Logik Problem, was ich bisher nicht richtig verstanden habe.

 

Und zwar wird in der Shell des Hosts (unRaid) und z.B. in der Shell von vaultwarden über den Befehl "date" die korrekte Zeit angezeigt. Wenn ich allerdings in die Diagnostic von vaultwarden gehe, wird mir angezeigt (siehe Anhang), dass die servertime (welche korrekt ist) 15:19 UTC ist, browsertime allerdings 2h zurück ist (weswegen ich kein TOTP nutzen kann, das ist auch der Grund weshalb ich auf der Fehlersuche bin). Bei CloudberryBackup ist mir dann aufgefallen, dass dort ein ähnliches Problem ist. Backup soll um 4 Uhr morgens gemacht werden, wird aber schon um 2 Uhr morgens gestartet.

 

Selbst wenn ich die Zeitzone bei unRaid ändere, ändert das nichts an der Zeit die z. B. in vaultwarden über die diagnostic angezeigt wird. Sowohl servertime, als auch browsertime bleiben identisch.

 

Ich bin mir nicht sicher, an welcher Stelle ich jetzt suchen soll. Habt ihr eine Idee?

 

vg, alex7

Edited June 23, 2022 by alex7

[ich777]

18 hours ago, alex7 said:

Wenn ich allerdings in die Diagnostic von vaultwarden gehe, wird mir angezeigt (siehe Anhang), dass die servertime (welche korrekt ist) 15:19 UTC ist, browsertime allerdings 2h zurück ist (weswegen ich kein TOTP nutzen kann, das ist auch der Grund weshalb ich auf der Fehlersuche bin). Bei CloudberryBackup ist mir dann aufgefallen, dass dort ein ähnliches Problem ist. Backup soll um 4 Uhr morgens gemacht werden, wird aber schon um 2 Uhr morgens gestartet.

Ich würd die Frage im Vaultvarden Support Thread stellen.

Normalerweise wenn du eine Variable mit dem Key: TZ im Docker Template anlegst mit dem Value: Europe/Berlin oder Europe/Vienna oder was auch immer dann sollte der Container die Richtige Zeit übernehmen.

 

Ich weiß leider nicht ob der Vaultwarden container die variable unterstützt, sollte aber zumindest wenn er Debian basiert ist (ich glaub wenn er Ubuntu basiert ist funktioniert das nicht weil es dort einen Bug gibt meines wissens).

 

Vergiss bitte nicht das unsere Zeitzone normalerweise UTC +2 ist.

[alex7]

Ich habe mir gerade nochmal die Date and Timesettings bei unRaid angeschaut. Es sieht nun bei mir so aus (siehe Bild)

Wieso wird die Uhrzeit zwei Stunden im voraus angezeigt? Irgendwo habe ich auch gelesen, dass es evtl. mit dem BIOS zu tun hat, kann das sein?

 

Ich habe das Topic vielelicht falsch benannt, weil es ist anscheinend grundsätzlich ein Problem von unRaid. Wenn ich rein UTC auswähle in der Zeitzone, stimmt die Uhrzeit mit der deutschen Zeit.

 

 

[ich777]

2 hours ago, alex7 said:

Ich habe das Topic vielelicht falsch benannt, weil es ist anscheinend grundsätzlich ein Problem von unRaid.

Eher weniger...

 

Momentan haben wir UTC+2 da wir Sommerzeit haben. Wie gesagt ich würde hier eher einen Post im Support Thread von Valtwarden machen anstatt hier und auch eher deinem Browser die Schuld zu schieben weil der die Ziet UTC +0 anzeigt soweit ich von deinem Screenshot sehen kann.

 

Das hat auch eher weniger mit der Zeit des Hosts (Unraid) zu tuhen. Hast du denn schon versucht wie oben beschrieben eine Variable mit TZ zu erstellen?

 

[alex7]

Also da andere Container auch betroffen sind und die Uhrzeit grundsätzlich falsch läuft in Unraid, denke ich nicht dass der Fehler bei Vaultwarden liegt. Tatsächlich habe ich da schon ein offenes Topic, das ich vor diesem hier gemacht habe. Ursprünglich dachte ich nämlich auch es läge an Vaultwarden. 
 

wenn ich in Unraid UTC+1 Europe/Berlin einstelle haben wir zB statt tatsächlich 14 Uhr, 16 Uhr. Stelle ich es auf „UTC - Coordinated Universal Time“ (sprich, ohne Zeitzone) ist die Uhrzeit korrekt in Unraid.

 

Und Ja, die Variable hatte ich schon früh ausprobiert, aber Vaultwarden unterstützt diese wohl nicht. 

 

Edited June 24, 2022 by alex7

[mgutt]

Du hast ja wilde Zeitserver hinterlegt. Mal in den syslogs geschaut, ob es evtl Fehler bei der Verbindung dahin gibt?

 

Meine Einstellungen:

 

Bei dir fällt auf, dass kein CEST als Zeitzone beim Datum steht. Keine Ahnung warum das bei dir anders ist.

[hawihoney]

Blöde Frage: Warum tragt Ihr die individuellen Zeitserver in Unraid ein, statt den Router zu verwenden? In meinem Router sind diese eingetragen "time.cloudflare.com; 2.europe.pool.ntp.org" und der Router versorgt dann alle Geräte im eigenen Netz. So muss nicht jedes Gerät nach draußen abfragen.

 

[ich777]

11 minutes ago, hawihoney said:

Blöde Frage: Warum tragt Ihr die individuellen Zeitserver in Unraid ein, statt den Router zu verwenden? In meinem Router sind diese eingetragen "time.cloudflare.com; 2.europe.pool.ntp.org" und der Router versorgt dann alle Geräte im eigenen Netz. So muss nicht jedes Gerät nach draußen abfragen.

@alex7 hat doch eigene Zeitserver eingetragen, aber das kann auch genau das Problem sein in seinem Fall.

 

Gut das du darauf hingewiesen hast...

[hawihoney]

2 hours ago, ich777 said:

hat doch eigene Zeitserver eingetragen, aber das kann auch genau das Problem sein in seinem Fall.

 

Ich glaube wir reden gerade aneinander vorbei. Statt die individuellen Zeitserver in Unraid einzutragen, sehe ich eine solche Konfiguration eigentlich an zentraler Stelle des eigenen Netzwerks - dem Router. Dann trägt man in Unraid, und allen weiteren Geräten im eigenen Netzwerk, nur noch den Router als Zeitserver ein (z.B. Fritzbox 192.168.178.1).

 

Und genau darauf zielte meine OT Frage ab: Wieso sehe ich hier sehr oft im Unraid Server externe Zeitserver? Hat das irgendwelche Vorteile? Ich ging bisher davon aus, dass es eher nachteilig ist.

 

[ich777]

8 minutes ago, hawihoney said:

Ich glaube wir reden gerade aneinander vorbei. Statt die individuellen Zeitserver in Unraid einzutragen, sehe ich eine solche Konfiguration eigentlich an zentraler Stelle des eigenen Netzwerks - dem Router. Dann trägt man in Unraid, und allen weiteren Geräten im eigenen Netzwerk, nur noch den Router als Zeitserver ein (z.B. Fritzbox 192.168.178.1).

Nein, glaub ich nicht, ich verstehe dich schon.

 

Aber er hat ja, wie du oben in seinem Screenshot siehst, eigene Zeitserver eingetragen, vielleicht liegt dort das Problem...

 

Ich verstehe schon was du damit sagen willst aber vielleicht liefern die Zeitserver die er eingetragen hat die Zeit anders, wie @mgutt schon erwähnte wird bei ihm kein CEST oder sonstiges angezeigt.

[alex7]

Also ich habe das jetzt mal so eingestellt:

- in der FRITZ!Box den Zeitserver mal geändert auf ptbtime1.ptb.de

- in unraid nur die FRITZ!Box eingetragen

- Zeitzone in Unraid „normal“ auf Europe/Berlin+1

 

Trotz allem ist die Zeit noch zwei Stunden im Voraus. Das wirkt so, als ob er die richtige Zeit bekommt, aber durch die eingestellte Zeitzone NOCHMAL zwei Stunden drauf rechnet. Ich kann es mir aber nicht erklären. 

[mgutt]

Wie ich777 schon meinte, ist nicht der Zeitserver dein Problem, sondern irgendwas in den Unraid Einstellungen stimmt nicht.

 

Gib mal bitte das alles in der Konsole ein:

 

Das sollte die Zeit deiner Zeitzone zurückgeben:

date

 

 

Das hier sollte die UTC Zeit zurückgeben:

date -u

 

 

Das sind die Dateien, die Unraid verwendet um die Zeitzone des Servers festzulegen:

 

ls -l /etc/localtime*

 

 

Wir prüfen, dass deren Inhalt identisch ist:

 

md5sum /etc/localtime
md5sum /usr/share/zoneinfo/Europe/Berlin

 

 

Grundeinstellungen zur Sprache des Servers (da sollte nichts relevantes für die Zeitzone bei rauskommen, aber wir fragen es einfach mal ab):

 

printenv | grep -P '(LC|LANG)'

 

 

 

Das liest die Zeit vom BIOS aus:

 

 

hwclock --show

 

 

Das korrigiert die Zeit vom BIOS (mit --test simuliert es das nur), falls die zu schnell oder zu langsam "tickt":

 

hwclock --verbose --test --date --set

 

[mgutt]

4 hours ago, hawihoney said:

Blöde Frage: Warum tragt Ihr die individuellen Zeitserver in Unraid ein, statt den Router zu verwenden? In meinem Router sind diese eingetragen "time.cloudflare.com; 2.europe.pool.ntp.org" und der Router versorgt dann alle Geräte im eigenen Netz. So muss nicht jedes Gerät nach draußen abfragen.

 

 

Vermutlich hast du damit nur ein Gerät von vielen an deinen Router gebunden. zB Android nutzt seinen eigenen Zeitserver:

https://stackoverflow.com/questions/14381005/is-android-using-ntp-to-sync-time#comment31821643_14523190

 

Und ich denke mal jedes Gerät hat seine eigenen Werte hinterlegt, statt darauf zu "hoffen", dass der Router das kann.

 

Der Standard-Intervall ist übrigens 17 Minuten:

https://stackoverflow.com/a/45244298/318765

 

 

 

[hawihoney]

2 hours ago, mgutt said:

Android nutzt seinen eigenen Zeitserver

 

Danke für den Link. Wusste ich noch nicht. Alle anderen Devices gehen aber über den Router bei uns.

 

[DataCollector]

6 hours ago, hawihoney said:

Blöde Frage: Warum tragt Ihr die individuellen Zeitserver in Unraid ein, statt den Router zu verwenden?

Weil ein neu startender Router (nach Stromausfall) in aller Regel keine Stützbatterie hatte um die Zeit korrekt zu halten.

Erst wenn er wieder online ist und sich snchronisiert hat kennt er die aktuelle Zeit.

Das ist bei Ausfallsicherung per MultiWAN und ggf. mehreren Routern ungünstig.

Meine Primäre Fritzbox mach aktuell nur für eine WAN    die Anbindung und hat seit 2 Wochen schon 2 komplette Neustarts hingelegt (aktuell tippe ich auf schwächelndes Netzteil).

Meine HardwareFirewall handelt die WAN Anbindungen.

 

6 hours ago, hawihoney said:

In meinem Router sind diese eingetragen "time.cloudflare.com; 2.europe.pool.ntp.org" und der Router versorgt dann alle Geräte im eigenen Netz.

Wenn er erreichbar ist und die aktuellen Zeiten hat (also online ohne Stromausfall).

 

6 hours ago, hawihoney said:

So muss nicht jedes Gerät nach draußen abfragen.

Kann man so machen.

[alex7]

7 hours ago, mgutt said:

Wie ich777 schon meinte, ist nicht der Zeitserver dein Problem, sondern irgendwas in den Unraid Einstellungen stimmt nicht.

 

Gib mal bitte das alles in der Konsole ein:

 

Das sollte die Zeit deiner Zeitzone zurückgeben:

date

 

 

Das hier sollte die UTC Zeit zurückgeben:

date -u

 

 

Das sind die Dateien, die Unraid verwendet um die Zeitzone des Servers festzulegen:

 

ls -l /etc/localtime*

 

 

Wir prüfen, dass deren Inhalt identisch ist:

 

md5sum /etc/localtime
md5sum /usr/share/zoneinfo/Europe/Berlin

 

 

Grundeinstellungen zur Sprache des Servers (da sollte nichts relevantes für die Zeitzone bei rauskommen, aber wir fragen es einfach mal ab):

 

printenv | grep -P '(LC|LANG)'

 

 

 

Das liest die Zeit vom BIOS aus:

 

 

hwclock --show

 

 

Das korrigiert die Zeit vom BIOS (mit --test simuliert es das nur), falls die zu schnell oder zu langsam "tickt":

 

hwclock --verbose --test --date --set

 

 

@mgutt danke erstmal für die ausführliche Erklärung!

 

Ich habe die Befehle mal ausgeführt. Mir ist aufgefallen, dass bei mir der Pfad zur Zeitzone fehlt. Hast du den manuell eingetragen?

 

root@SERVERv1:~# date
Sat Jun 25 21:32:36 CEST 2022

root@SERVERv1:~# date -u
Sat Jun 25 19:32:52 UTC 2022

root@SERVERv1:~# ls -l /etc/localtime
-rw-r--r-- 1 root root 2298 Jun 25 21:31 /etc/localtime

root@SERVERv1:~# md5sum /etc/localtime
7db6c3e5031eaf69e6d1e5583ab2e870  /etc/localtime

root@SERVERv1:~# printenv | grep -P '(LC|LANG)'
LANG=en_US.UTF-8
LC_COLLATE=C

root@SERVERv1:~# hwclock --show
2022-06-25 21:35:33.949605+02:00

root@SERVERv1:~# hwclock --verbose --test --date --set
hwclock from util-linux 2.37.4
System Time: 1656185772.186420
Trying to open: /dev/rtc0
Using the rtc interface to the clock.
Assuming hardware clock is kept in UTC time.
Waiting for clock tick...
...got clock tick
Time read from Hardware Clock: 2022/06/25 19:36:13
Hw clock time : 2022/06/25 19:36:13 = 1656185773 seconds since 1969
Time since last adjustment is 1656185773 seconds
Calculated Hardware Clock drift is 0.000000 seconds
2022-06-25 21:36:12.168237+02:00
Test mode: nothing was changed.

 

[mgutt]

Ändere mal bitte in den Datumseinstellungen die Zeitzone auf eine andere Zone und dann zurück auf Berlin.

[alex7]

Das habe ich aus Frust mind. schon 5-10 mal gemacht 😞

[mgutt]

16 hours ago, alex7 said:

Mir ist aufgefallen, dass bei mir der Pfad zur Zeitzone fehlt

Du hast den Stern vergessen. So:

ls -l /etc/localtime*

 

Da der MD5 Hash aber genauso lautet wie bei mir, können wir davon ausgehen, dass auch bei dir Berlin gesetzt wurde.

 

War denn der Wert von "date" deine aktuelle Zeit?

[alex7]

1 hour ago, mgutt said:

Du hast den Stern vergessen. So:

ls -l /etc/localtime*

 

Da der MD5 Hash aber genauso lautet wie bei mir, können wir davon ausgehen, dass auch bei dir Berlin gesetzt wurde.

 

War denn der Wert von "date" deine aktuelle Zeit?

 

Du hast recht, die Zeitzone stimmt.

 

root@SERVERv1:/# date
Sun Jun 26 15:21:29 CEST 2022

root@SERVERv1:/# date -u
Sun Jun 26 13:21:31 UTC 2022

 

Also 'date' stimmt nicht, das ist schon zwei Stunden voraus. 'date -u' stimmt dagegen.

 

Die BIOS Zeit stimmt auch nicht, die er bei dem Befehl ausgibt, weil er da zwei Stunden drauf rechnet. Ist das mein Problem? Wenn ich ins BIOS gehe und die Zeit prüfe stimmt sie.

[mgutt]

8 minutes ago, alex7 said:

Also 'date' stimmt nicht, das ist schon zwei Stunden voraus. 'date -u' stimmt dagegen.

Das darf nicht sein. Guckst du:

 

Versuch mal manuell die Zeit anzupassen:

ntpdate -s time1.google.com

 

Alternativ im Debug Modus:

ntpdate -d -s time1.google.com

 

[alex7]

So, ich habe beides mal ausprobiert. Leider hat sich nichts geändert.

 

root@SERVERv1:~# date
Sun Jun 26 17:11:00 CEST 2022
root@SERVERv1:~# ntpdate -s time1.google.com
root@SERVERv1:~# date
Sun Jun 26 17:11:13 CEST 2022
root@SERVERv1:~# ntpdate -d -s time1.google.com
26 Jun 17:11:31 ntpdate[17544]: ntpdate [email protected] Fri May 21 19:02:16 UTC 2021 (1)
Looking for host time1.google.com and service ntp
216.239.35.0 reversed to time1.google.com
host found : time1.google.com
transmit(216.239.35.0)
receive(216.239.35.0)
transmit(216.239.35.0)
receive(216.239.35.0)
transmit(216.239.35.0)
receive(216.239.35.0)
transmit(216.239.35.0)
receive(216.239.35.0)

server 216.239.35.0, port 123
stratum 1, precision -20, leap 00, trust 000
refid [GOOG], root delay 0.000000, root dispersion 0.000107
reference time:      e662d95f.9103d310  Sun, Jun 26 2022 15:10:55.566
originate timestamp: e662d95f.9103d313  Sun, Jun 26 2022 15:10:55.566
transmit timestamp:  e662f5a9.490d4bcc  Sun, Jun 26 2022 17:11:37.285
filter delay:  0.04666    0.04520    0.04550    0.04532
               ----       ----       ----       ----
filter offset: -7241.7283 -7241.7286 -7241.7287 -7241.7287
               ----       ----       ----       ----
delay 0.04520, dispersion 0.00009, offset -7241.728667

26 Jun 17:11:37 ntpdate[17544]: step time server 216.239.35.0 offset -7241.728667 sec
root@SERVERv1:~# date
Sun Jun 26 17:11:43 CEST 2022

 

[alex7]

Also ich bin mir jetzt nicht sicher, ob die letzten Befehle die du mir genannt hast, nach dem Reboot etwas bewirkt haben. Allerdings hatte ich nun parallel noch eine Vermutung und habe den Server von meinem Switch im Serverschrank direkt auf die Fritzbox gesteckt. Und ich habe nach dem Reboot nun tatsächliche die korrekt Zeit 

 

Ich gehe mal ganz stark davon aus, dass der Switch das Problem war  ich hatte mit einer anderen Anwendung auf meinem PC auch mal das Problem und musste direkt an die Fritzbox. Was letztendlich das Problem auf dem Switch ist, kann ich nicht ganz nachvollziehen.

 

Trotzdem danke ich nochmal allen die etwas beigesteuert haben und speziell nochmal an @mgutt und @ich777 für die Mühe. Ich versuche dann mal den Fehler beim Switch zu suchen.

[mgutt]

17 minutes ago, alex7 said:

Was letztendlich das Problem auf dem Switch ist, kann ich nicht ganz nachvollziehen.

Sehen tue ich jetzt auch nichts. Weil ich hätte dann erwartet, dass "ntpdate" einen Fehler zurückgibt.

 

 

Dass dein Datum anders aussieht als bei uns, dürfte übrigens an der Einstellung liegen:

 

 

Ich denke du hast da explizit DD-MM-YYYY ausgewählt und dadurch fliegt bei dir das "CEST" bei der Darstellung raus. Trotzdem sollte natürlich das Datum richtig angezeigt werden, egal was man da gewählt hat.