Univention Bugzilla – Bug 25752
NTPD beendet sich wenn Zeitdifferenz zu groß
Last modified: 2013-04-10 14:53:30 CEST
Wenn die Zeitdifferenz auf einer UCS 3.0 Maschine (mit univention-base-files aus den errata10 bzw 3.0-1) zu groß ist, beendet sich der ntpd. Wir starten ntpd eigentlich mit "-g" um das zu verhindern, aber das reicht wohl noch nicht. ps aux| grep ntp ntp 28105 0.0 0.1 4396 1756 ? Ss 09:54 0:00 /usr/sbin/ntpd -p /var/run/ntpd.pid -u 106:115 -g -g Normally, ntpd exits with a message to the system log if the offset exceeds the panic threshold, which is 1000 s by default. This option allows the time to be set to any value without restriction; however, this can happen only once. If the threshold is exceeded after that, ntpd will exit with a message to the system log. This option can be used with the -q and -x options.
Das Problem tritt u.a. auch durch das nächtliche suspend/resume auf: Dadurch bleibt für die VM die Zeit stehen und nach dem Resume ist die Zeitdifferenz zu groß, so daß sich dann ntpd weigert, die Zeit zu korrigieren. VMWare gibt unter <http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006427> die Empfehlung, in der /etc/ntp.conf folgendes zu ergänzen: tinker panic 0 Das sollte über eine UCR-Variable konfigurierbar sein und ggf. automatisch bei UCS-Installationen in einer VM gesetzt werden <http://people.redhat.com/~rjones/virt-what/>.
Das Setzen von "tinker panic 0" funktioniert soweit mit meinem VMs, allerdings dauert es nach dem Resume 2h15m bis der ntpd dann endlich die Zeit übernimmt: # while date; do sleep 1m ; done | tee /tmp/ntp.log Mo 2. Jul 21:01:59 CEST 2012 ... Mo 2. Jul 23:16:00 CEST 2012 Mi 4. Jul 11:38:53 CEST 2012 Siehe auch Bug #27807 für einen unschönen Fehler, der durch die Problematik hervorgerufen wird.
*** Bug 28695 has been marked as a duplicate of this bug. ***
Ggf. auch noch Punkt 2 an Bug 28695 comment 0 beachten.
Gibt es einen Zeitplan, ab wann "tinker panic 0" in den Templatefiles enthalten sein wird?
(In reply to comment #1) > Das Problem tritt u.a. auch durch das nächtliche suspend/resume auf: Dadurch > bleibt für die VM die Zeit stehen und nach dem Resume ist die Zeitdifferenz zu > groß, so daß sich dann ntpd weigert, die Zeit zu korrigieren. > > VMWare gibt unter > <http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1006427> > die Empfehlung, in der /etc/ntp.conf folgendes zu ergänzen: > tinker panic 0 > > Das sollte über eine UCR-Variable konfigurierbar sein und ggf. automatisch bei > UCS-Installationen in einer VM gesetzt werden > <http://people.redhat.com/~rjones/virt-what/>. Was spricht dagegen es immer zu setzen?
(In reply to comment #6) > (In reply to comment #1) > > tinker panic 0 > > Was spricht dagegen es immer zu setzen? AFAIK nichts. Die Einstellung wird übrigens auch an Bug #15604 erwähnt, wo es um Zeitquellen für VMs geht.
(In reply to comment #7) > (In reply to comment #6) > > (In reply to comment #1) > > > tinker panic 0 > > > > Was spricht dagegen es immer zu setzen? > > AFAIK nichts. > Die Einstellung wird übrigens auch an Bug #15604 erwähnt, wo es um Zeitquellen > für VMs geht. OK, dann sollten wir es mit UCS 3.1-1 umsetzen, da wir noch andere Anpassungen im Bereich NTP für 3.1-1 haben.
(In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #6) > > > (In reply to comment #1) > > > > tinker panic 0 > > > > > > Was spricht dagegen es immer zu setzen? > > > > AFAIK nichts. > > Die Einstellung wird übrigens auch an Bug #15604 erwähnt, wo es um Zeitquellen > > für VMs geht. > > OK, dann sollten wir es mit UCS 3.1-1 umsetzen, da wir noch andere Anpassungen > im Bereich NTP für 3.1-1 haben. UCR Variable ntp/tinker/panic wurde hinzugefügt, wird im postinst auf "0" (Sekunden) gesetzt wenn nicht bereits gesetzt und im Template für /etc/ntp.conf verwendet. univention-base-files (2.0.14-1) unstable; urgency=low * added UCR variable ntp/tinker/panic, which can be used to configure the maximum allowed time difference (in seconds) to the ntp server until the ntpd stops synchronising. It is set to 0 in postinst in order to allow any time difference per default (Bug #25752) svn 39436
Verified: * Auf Master + Backup habe ich mammut als timeserver eingetragen und ntp neu gestartet. Nach 0.2 Ewigkeiten haben die beiden dann ihren Zeit-offset zu mammut auf 0 gesetzt und nach ein paar Entscheidungsschwierigkeiten (siehe Bug 30854) haben sie sich dann nach ca. 0.5 Ewigkeiten auch als ntp_sync gegen mammut stabilisiert. "Kurze Zeit später" (alles is relativ) hat dann der Slave ohne manuelle Fremdeinwirkung seinen mehrstündigen Rückstand auf einen Schlag korrigiert. No Process has been harmed during the QA of this Bug. tinker panik 0 sei Dank. * Changelog Ok.
UCS 3.1-1 has been released: http://download.univention.de/doc/release-notes-3.1-1_en.pdf http://download.univention.de/doc/release-notes-3.1-1.pdf If this error occurs again, please use "Clone This Bug".
Nach dem Starten einer VM dauert es teilweise immer noch recht lange, bis sich der NTPd wieder aufsynchronisiert hat. Ggf. wäre hier zusätzlich die Option "iburst" sinnvoll, solange als Zeitquelle eine UCS (und damit garantiert kein öffentlicher) NTP-Server verwendet wird: <http://docs.fedoraproject.org/en-US/Fedora/15/html/Deployment_Guide/sect-Date_and_Time_Configuration-Command_Line_Configuration-Network_Time_Protocol.html> <http://support.ntp.org/bin/view/Support/StartingNTP4#Section_7.1.4>