ntp.conf hohen Zeitdrift langsam anpassen und nicht hardcore

[pangu]

Hi Leute,

ich hab einen verdammt wichtigen Server, der leider Gottes -man möge es nicht glauben- 10min falsch geht! Es handelt sich sogar um einen SAP-Produktivserver *autsch* ich teste gerade an diversen anderen Hosts (bei denen ich kein Problem mit Zeitsprünge hätte) wie sich das mit dem NTP-Dienst verhält. Dabei setz ich manuell die Zeit ca. 10min vor oder zurück, so daß sie falsch geht. Dann editiere ich die ntp.conf:

Wenn ich die Zusatzoption IBURST verwende

Code: Alles auswählen

server 192.168.5.100 iburst

und den NTP-Dienst restarte, dann sehe ich deutlich, dass die Uhrzeit von der falschen Zeit 13:50 schlagartig auf die richtige Zeit 14:00 gesynct wird. Das ganze dauert ca. 5-10 Sekunden würde ich sagen.

Dann stell ich die Uhr wieder falsch. Wenn ich OHNE IBURST das Ganze verwende:

Code: Alles auswählen

server 192.168.5.100

und den NTP-Dienst restarte, dann dauert das zwar jetzt ca. 3 Minuten, aber die springt dann trotzdem schlagartig um. Wie kann das sein? Was muss ich verwenden, damit sich die sehr grosse Zeitabweichung von 10min schleichend an die richtige Uhrzeit anpasst? Ich denke wenn das im SAP-System so passieren würde, wäre das sicherlich nicht gut :p

[rendegast]

Beim chrony gibt es dieses:

# Stop bad estimates upsetting machine clock.

maxupdateskew 100.0
...
# This directive forces `chronyd' to send a message to syslog if it
# makes a system clock adjustment larger than a threshold value in seconds.

#logchange 0.5
logchange 0.1

600sec aber in ~ 1/100sec-Schritten aufzuholen, naja, s.u. ~ Wochen.
Das entsprechende "ntpdate" war:

Code: Alles auswählen

#!/bin/sh
...
PASSWORD=`awk '$1 ~ /^1$/ {print $2; exit}' /etc/chrony/chrony.keys`
cat << EOF | /usr/bin/chronyc | sed '/^200 OK$/d'
password $PASSWORD
sources -v
activity
online
makestep
EOF
} >> $LOGDATEI

Irgendwann war das Problem der schnellen Drift aber wieder erledigt
(entweder durch kernel oder chrony) und 'makestep' wurde unnötig.


Beim ntpd ist normalerweise eingeschaltet:

Code: Alles auswählen

       -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.

Interessant wären aber auch diese:

Code: Alles auswählen

       -q     Exit  the ntpd just after the first time the clock is set.  This behavior mimics that
              of the ntpdate program, which is to be retired.  The -g and -x options  can  be  used
              with this option.  Note: The kernel time discipline is disabled with this option.
...
        -x     Normally, the time is slewed if the offset is less than the step threshold, which  is
              128  ms by default, and stepped if above the threshold.  This option sets the thresh‐
              old to 600 s, which is well within the accuracy window to  set  the  clock  manually.
              Note: Since the slew rate of typical Unix kernels is limited to 0.5 ms/s, each second
              of adjustment requires an amortization interval of 2000 s.  Thus,  an  adjustment  as
              much as 600 s will take almost 14 days to complete.  This option can be used with the
              -g and -q options.  Note: The kernel time discipline is disabled with this option.

für entsprechende Optionen in der ntp.conf müßte wohl ntp-doc durchgelesen werden.
Dort wird bei '-x' auch auf ein 'tinker'-Kommando verwiesen ("sacred system-parameters", "dangerous").





--------------------------------

Es handelt sich sogar um einen SAP-Produktivserver *autsch*

Ein ntpclient-Dienst hat normalerweise die Kerneluhr unter seiner Fuchtel,
und regelt freq und tick entsprechend.

Code: Alles auswählen

# ./adjtimex -p
         mode: 0
       offset: 0
    frequency: 2536411          <<<<<<<<<<<<<<<<<<<<
     maxerror: 16000000
     esterror: 16000000
       status: 64
time_constant: 2
    precision: 1
    tolerance: 32768000
         tick: 10000           <<<<<<<<<<<<<<<<<<
     raw time:  1345127016s 114734us = 1345127016.114734
 return value = 5

Kann es sein, daß auf dem SAP durch irgendeine Policy der ntp das nicht darf,
sodaß sich da die 10min akkumulieren? -> Logfiles

[pangu]

Ich denke einfach, dass es nie richtig eingestellt wurde und nicht auf die Zeitsynchronisation geachtet wurde. So frech behaupte ich das auch nur weil ich auf all den anderen Servern und Hosts das Chaos live mitansehen durfte. Deswegen bin ich ja gerade dabei das ganze zu beheben, um endlich eine synchrone Zeit in der Domäne herzustellen. Ich werde dein Posting nochmals durchgehen, aber für heute ist genug. Die Birne qualmt und ich geh in den Feierabend. Bis dann und nochmals danke.