chrony

[Kermit24]

Hallo,
seit Jahren habe ich es nicht hinbekommen chrony in debian vernünftig ans Laufen zu bekommen: Chrony ist überhaupt der unzuverlässigste Dienst, den ich kenne: Ich habe einen DSL-Zugang, der sich 24stündlich neueinwählt (Zwangstrennung).

In der von debian mitgelieferen conf-file stehen:

Code: Alles auswählen

server 0.debian.pool.ntp.org offline minpoll 8
server 1.debian.pool.ntp.org offline minpoll 8
server 2.debian.pool.ntp.org offline minpoll 8
server 3.debian.pool.ntp.org offline minpoll 8

In /etc/ppp/ipup.d/chrony entsprechende Befehle um das ganze online zu setzen.

Nur kommt das ppp-Script offensichtlich zu schnell: Direkt nach der Einwahl scheint chrony die Server (zumindest manchmal) nicht zu finden und löscht sie wohl einfach aus seiner internen Liste. Verbinde ich mich mit chronyc und gebe password und online ein, so sagt er mir "503 no sources". Das ist wohl ein remanenter Schaden, der nur durch ein Neustart des chrony-daemons behoben werden kann? Oder kann ich chrony irgendwie zwingen, die Serverliste aus der chrony.conf neueinzulesen über das ppp-script?

[Kelpin]

Code: Alles auswählen

/etc/init.d/chrony restart

funkoniert bei mir. Ich habe mir allerdings Quellen gesucht, die meistens erreichbar sind.

[rendegast]

Direkt nach der Einwahl scheint chrony die Server (zumindest manchmal) nicht zu finden und löscht sie wohl einfach aus seiner internen Liste.

'chronyc' -> 'sources' ?

In /etc/ppp/ip-up.d/chrony ein 'sleep' einbauen?

Die Zwangstrennung führt zu einem ip-down/ip-up ?



Nebenbei,
da chrony eine große Zeitabweichung (10-1000s oder mehr) von allein nicht korrigieren kann,
vielleicht ein 'makestep' in das Skript einbauen?

[Kermit24]

Code: Alles auswählen

/etc/init.d/chrony restart

funkoniert bei mir. Ich habe mir allerdings Quellen gesucht, die meistens erreichbar sind.

Und genau das wollte ich ja nicht (Neustart des Daemons). Aber wenn es anders nicht geht, dann baue ich halt das in das ip-up script ein, statt den Weg über chronyc und online.

[Kermit24]

Es läuft wieder nicht! Auch nach Neustart von chronyd:

Code: Alles auswählen

chronyc> sourcestats
210 Number of sources = 2
Name/IP Address            NP  NR  Span  Frequency   Freq Skew   Std Dev
========================================================================
ptbtime2.ptb.de             1   0     0       0.000    2000.000  4000ms
ptbtime1.ptb.de             1   0     0       0.000    2000.000  4000ms
chronyc> tracking
Reference ID    : 127.127.1.1 (127.127.1.1)
Stratum         : 10
Ref time (UTC)  : Mon Sep  6 19:26:25 2010
System time     : 0.000000 seconds fast of NTP time
Frequency       : 14.435 ppm fast
Residual freq   : 0.000 ppm
Skew            : 0.000 ppm
Root delay      : 0.000000 seconds
Root dispersion : 0.000000 seconds

Woran kann das liegen? Auch ein 'online' ändert nichts. Meine Uhr geht wieder rund 5 Minuten falsch. Unter 'tracking' steht normalerweise eine Server-IP von den Sourcen. Warum jetzt nicht mehr?

NACHTRAG:
Auch bei anderen Servern klappt nichts. Doch dann: Scheinbar braucht Chrony eine halbe Ewigkeit, bis es merkt, dass die Uhr falsch geht:

Code: Alles auswählen

`--# chronyd -d
sys_linux.c:649:(get_version_specific_details)[06-19:31:58] Initial txc.tick=10000 txc.freq=-945095 (-14.42100525) txc.offset=0 => hz=100 shift_hz=7
sys_linux.c:665:(get_version_specific_details)[06-19:31:58] set_config_hz=0 hz=100 shift_hz=7 basic_freq_scale=1.28000000 nominal_tick=10000 slew_delta_tick=833 max_tick_bias=1000
sys_linux.c:703:(get_version_specific_details)[06-19:31:58] Linux kernel major=2 minor=6 patch=32
sys_linux.c:787:(get_version_specific_details)[06-19:31:58] calculated_freq_scale=0.99902439 freq_scale=0.99902439
sources.c:660:(SRC_SelectSource)[06-19:40:32] Selected source 131.234.137.24
reference.c:276:(maybe_log_offset)[06-19:40:32] System clock wrong by 251.047168 seconds, adjustment started

[rendegast]

System clock wrong by 251.047168 seconds, adjustment started

Für die Korrektur braucht chrony auch Ewigkeiten,
"brutal" und schnell mit 'makestep':

Code: Alles auswählen

#!/bin/sh
ntpdate -q ....

PASSWORD=`awk '$1 ~ /^1$/ {print $2; exit}' /etc/chrony/chrony.keys`
cat << EOF | /usr/bin/chronyc | sed '/^200 OK$/d'
password $PASSWORD
makestep
EOF

ntpdate -q ....

(nach cron.weekly/chrony)


Eventuell kommt der Fehler durch Auswertung der RTC-Zeit und einer noch nicht angepaßten adjtime?
Bei mir habe ich hwclockfirst.sh deaktiviert. (durch Entzug der x-Bits, hwclock.sh aber unverändert)
Eventuell auch /etc/default/rcS:HWCLOCKACCESS=[no|yes]