Zeitzone

Allgemeine Fragen zu Problemen. Keine Fehlerberichte oder Feature-Anfragen

Moderator: Securepoint

Antworten
Benutzeravatar
isential gmbh
Beiträge: 156
Registriert: Di 05.05.2015, 22:17
Kontaktdaten:

Zeitzone

Beitrag von isential gmbh »

Sehr geehrte Damen und Herren,
bei einer UMA-Installation (Version UMA 2.5.2) stellen wir fest, da die NTP-Server die Zeit nicht synchronisiert. Angegeben ist "Europe/Berlin/ntp.securepoint.de". Folgende Meldung wird ausgegeben: "NTP-Server nicht erreichbar oder Differenz zu groß, neuer Versuch in xxs".
In de Console läuft die mit "date" angezeigte Uhrzeit immer um zwei Stunden nach. Ich gehe daher davon aus, dass das darunter liegende System die falsche Zeitzone hat, obwohl in der Admin-Oberfläche die richtige angegeben ist.
Wenn ich mir z. B. Protokolle bzw. Logs anschaue, dann zeigen diese die richtige Uhrzeit an.
Ein Auszug des Logs (s. u.) zeigt mir, dass es Probleme mit der Uhrzeit hat:
daemon.info: Jun 10 16:34:39 clockspeed: sntpclock: warning: unable to read clock: timed out
user.notice: Jun 10 16:34:40 startsshd[9354]: shutting down service ssh
auth.info: Jun 10 16:34:40 sshd[9358]: Received signal 15; terminating.
daemon.info: Jun 10 16:34:40 clockspeed: sntpclock: warning: unable to read clock: timed out
daemon.info: Jun 10 16:34:41 clockspeed: sntpclock: warning: unable to read clock: timed out
daemon.info: Jun 10 16:34:41 clockspeed: sntpclock: fatal: time uncertainty too large
daemon.info: Jun 10 16:34:41 clockspeed: clockadd: fatal: data split across packets
daemon.info: Jun 10 16:34:41 clockspeed: ntp.securepoint.de: Resolver internal error
daemon.info: Jun 10 16:34:41 clockspeed: Setting system clock with master server at :
local3.info: Jun 10 16:34:42 uma.mhg.local nginx: 192.168.10.210 - - [10/Jun/2016:16:34:42 +0200] "POST /admin/tool/tool_run HTTP/1.1" 200 26 "https://192.168.10.211:11115/" "Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like Gecko"
daemon.info: Jun 10 16:34:42 clockspeed: sntpclock: warning: unable to read clock: timed out
local3.info: Jun 10 16:34:43 uma.mhg.local nginx: 192.168.10.210 - - [10/Jun/2016:16:34:43 +0200] "POST /admin/tool/tool_async_info_get HTTP/1.1" 200 607 "https://192.168.10.211:11115/" "Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like Gecko"
local3.info: Jun 10 16:34:43 uma.mhg.local nginx: 192.168.10.210 - - [10/Jun/2016:16:34:43 +0200] "POST /admin/tool/tool_user_async_info_get HTTP/1.1" 200 765 "https://192.168.10.211:11115/" "Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like Gecko"
daemon.info: Jun 10 16:34:43 clockspeed: sntpclock: warning: unable to read clock: timed out
user.notice: Jun 10 16:34:43 startsshd[9400]: shutting down service ssh
local3.info: Jun 10 16:34:44 uma.mhg.local nginx: 192.168.10.210 - - [10/Jun/2016:16:34:44 +0200] "POST /admin/tool/tool_async_info_delete HTTP/1.1" 200 16 "https://192.168.10.211:11115/" "Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like Gecko"
daemon.info: Jun 10 16:34:44 clockspeed: sntpclock: warning: unable to read clock: timed out
local3.info: Jun 10 16:34:44 uma.mhg.local nginx: 192.168.10.210 - - [10/Jun/2016:16:34:44 +0200] "POST /admin/tool/tool_run HTTP/1.1" 200 26 "https://192.168.10.211:11115/" "Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like Gecko"
Bitte geben Sie uns schnell Bescheid, was wir machen müssen, damit die Zeitsynchronisierung funktioniert.
Vielen Dank!
René Ketterer

Christian Beyer
Securepoint
Beiträge: 157
Registriert: Mo 17.11.2008, 21:38
Kontaktdaten:

Beitrag von Christian Beyer »

Sehr geehrter Herr Ketterer, 

ist die Zeitdifferenz zwischen der System-Zeit und der Zeit des NTP-Servers zu groß wird die Zeit nicht automatisch angeglichen. 
Ansonsten könnte es zu Verfälschungen der Logs oder zu einer Beeinflussung von zeitgesteuerte Prozesse kommen.

Am besten setzen Sie die Zeit im BIOS des Systems korrekt. 
Damit vermeiden Sie einen Zeitsprung im laufenden Betrieb. 

Mit freundlichen Grüßen, 

Christian Beyer

Benutzeravatar
isential gmbh
Beiträge: 156
Registriert: Di 05.05.2015, 22:17
Kontaktdaten:

Beitrag von isential gmbh »

Die Zeit im BIOS des Host-PC's ist korrekt. Zur Vervollständigung der Konfiguration:
  • Windows-Host-PC mit Windows 10 Prof. und Hyper-V
  • Die UMA läuft virtuell auf dem Hyper-V
Wir haben eine zweite, bis auf die Speicherkapazität gleich ausgestattete UMA im Einsatz, die die beschriebenen Probleme nicht anzeigt.

Benutzeravatar
isential gmbh
Beiträge: 156
Registriert: Di 05.05.2015, 22:17
Kontaktdaten:

Beitrag von isential gmbh »

Unter E-Mail-Server sehe ich ständig nur folgendes, was sich jede Minute wiederholt:

Code: Alles auswählen

info: Jun 28 11:20:05 sp_fetchmail: fetching mails from uma@domail.tld
err: Jun 28 11:20:05 sp_fetchmail: trying exchange workaround...
err: Jun 28 11:20:05 sp_fetchmail: Error connecting storage: connect
err: Jun 28 11:20:05 sp_fetchmail: Error connecting to mail.domain.tld.
Warum verhalten sich gleiche Installationen unterschiedlich? Was kann man sonst unternehmen, außer dem Vorschlag, die BIOS-Zeit umzustellen?

Benutzeravatar
Mario
Securepoint
Beiträge: 295
Registriert: Mi 04.04.2007, 10:47
Wohnort: Bäckerei

Beitrag von Mario »

Im BIOS ist bei der Sommerzeit die aktuelle Uhrzeit - 2 Stunden zu wählen. Bei Winterzeit -1 Stunde. Das nachtraeglich zu justieren kann zu Problemen fuehren, da bei Ihnen Dateien quasi in der Zukunft abgespeichert wurden. Bei einem falschen Datum kann es sogar passieren, das das Geraet nicht mehr bootet, da der Integritaetscheck fuer das Dateissystem wegen moeglicher Fehler des Dateissystems warnt. (Da die Vorhandenen Daten in der Zukunft liegen)

Ist die Uhrzeit im BIOS korrekt eingestellt sollte sich diese auch wieder synchronisieren.

Benutzeravatar
isential gmbh
Beiträge: 156
Registriert: Di 05.05.2015, 22:17
Kontaktdaten:

Beitrag von isential gmbh »

Wie sieht es heute mit diesem Problem aus? Wir haben immer noch, nach vier Jahren nach diesem Thread immer wieder Probleme mit einigen UMAs. Hier aktuell bei einem Kunden:

https://isential.de/pub/Securepoint/zeitdifferenz.png

Bild

Benutzeravatar
isential gmbh
Beiträge: 156
Registriert: Di 05.05.2015, 22:17
Kontaktdaten:

Beitrag von isential gmbh »

Heute wieder bei einem Kunden eine Zeitdifferenz von 561 Sekunden. 

Antworten