Seite 1 von 1

Zeitzone

Verfasst: Fr 10.06.2016, 16:38
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

Re: Zeitzone

Verfasst: Mo 13.06.2016, 12:51
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

Re: Zeitzone

Verfasst: Di 28.06.2016, 11:13
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.

Re: Zeitzone

Verfasst: Di 28.06.2016, 11:25
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?

Re: Zeitzone

Verfasst: Di 28.06.2016, 12:10
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.

Re: Zeitzone

Verfasst: Mo 27.04.2020, 07:55
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

Re: Zeitzone

Verfasst: Sa 16.05.2020, 10:07
von isential gmbh
Heute wieder bei einem Kunden eine Zeitdifferenz von 561 Sekunden.