NTP server na FBSD

[Miroslav Lachman]

Dan Lukes wrote:
> Miroslav Lachman napsal/wrote, On 10/20/09 23:35:
> 
>> Co me vsak v souvislosti s ntpd prekvapuje je to, ze i kdyz ho 
>> provozuji na vsech serverech, tak jsem pred casem vypozoroval mezi 
>> servery odchylku az 4 sekundy, coz mi prijde celkem dost.
> 
> 
> Me pripada, ze pri dlouhodobem provozu ma ntpd tendenci "ztracet 
> servery". Nevim, za jakych okolnosti k tomu dochazi, al erelativne casti 
> zjistim, ze n aserveru s velkym uptime ma ntpd v seznamu upstream 
> serveru jednu - a nebo taky klidne zadnou polozku. Pak pochopitelne 
> nesynchronizuje ...

Tak netrvalo ani moc dlouho a dneska jsem na ten zmineny problem dojel :(
Mame tu nekolik serveru, ktere poskytuji sluzby provazane tak, ze zavisi 
na synchronizovanem casu jednotlivych stroju (na jednom webserveru se 
generuji odkazy s casovou platnosti par sekund a na dalsim webserveru se 
kontroluji, kdyz je odchylka prilis velka, odkazy prestanou fungovat, 
zaroven je potreba mit stejny cas v aplikaci, jako je v databazi)
Dnes odkazy prestaly fungovat, tak jsem se mrknul na cas a i kdyz na 
vsech serverech bezi ntpd, cas se lisil velmi znacne:

root at odysseus ~/# ntpd -q
ntpd: time set +26.081711s

root at indy ~/# ntpd -q
ntpd: time set -5.140164s

root at imp ~/# ntpd -q
ntpd: time set +9.007542s

root at spare ~/# ntpd -q
[zadny vysledek]


root at odysseus ~/# ntpq -p
      remote        refid   st t when poll reach   delay   offset  jitter
========================================================================
  5ED0CEB2.cable. .INIT.    16 u 203d 1024    0    0.000    0.000 4000.00
  srv2.trusted.cz .INIT.    16 u    - 1024    0    0.000    0.000 4000.00
  kox.avn.cz      .INIT.    16 u 203d 1024    0    0.000    0.000 4000.00
  srv1.trusted.cz .INIT.    16 u 203d 1024    0    0.000    0.000 4000.00
  srv2.trusted.cz .INIT.    16 u 203d 1024    0    0.000    0.000 4000.00
  odine.cgi.cz    .INIT.    16 u 203d 1024    0    0.000    0.000 4000.00

root at indy ~/# ntpq -p
      remote        refid   st t when poll reach   delay   offset  jitter
========================================================================
  farnsworth.1270 .INIT.    16 u 203d 1024    0    0.000    0.000 4000.00
  visualserver.or .INIT.    16 u    - 1024    0    0.000    0.000 4000.00
  r5af245.net.upc .INIT.    16 u 203d 1024    0    0.000    0.000 4000.00
  voodoo.banbook. .INIT.    16 u 203d 1024    0    0.000    0.000 4000.00
  visualserver.or .INIT.    16 u 203d 1024    0    0.000    0.000 4000.00
  web1.euromise.c .INIT.    16 u 203d 1024    0    0.000    0.000 4000.00
  odine.cgi.cz    .INIT.    16 u 203d 1024    0    0.000    0.000 4000.00

root at imp ~/# ntpq -p
      remote        refid   st t when poll reach   delay   offset  jitter
========================================================================
  farnsworth.1270 .INIT.    16 u 203d 1024    0    0.000    0.000 4000.00
  visualserver.or .INIT.    16 u    - 1024    0    0.000    0.000 4000.00
  kox.avn.cz      .INIT.    16 u 203d 1024    0    0.000    0.000 4000.00
  voodoo.banbook. .INIT.    16 u 203d 1024    0    0.000    0.000 4000.00
  visualserver.or .INIT.    16 u 203d 1024    0    0.000    0.000 4000.00
  web1.euromise.c .INIT.    16 u 203d 1024    0    0.000    0.000 4000.00
  odine.cgi.cz    .INIT.    16 u 203d 1024    0    0.000    0.000 4000.00

root at spare ~/# ntpq -p
      remote           refid      st t when poll reach   delay   offset 
  jitter
==============================================================================
-ryzome.info     192.93.2.20      2 u  575 1024  377   29.511   -3.905 
  0.104
*odine.cgi.cz    195.113.144.201  2 u  610 1024  377    0.670    1.283 
  0.034
+voodoo.banbook. 195.113.144.201  2 u  559 1024  377    0.970    2.516 
  0.028
+xm01.qls.cz     147.231.19.43    2 u  595 1024  377    0.936    1.832 
  0.100
-web1.euromise.c 195.113.144.201  2 u  607 1024  377    0.958   -3.251 
  0.187


Co maji prvni tri servery spolecneho? Vysoky uptime. Coz potvrzuje 
Danova slova o tom, ze servery s dlouhym uptimem se postupne prestanou 
synchronizovat.
Ze to tak je uz ted vim a zajima me, proc to tak je? Kvuli cemu k tomu 
dojde a hlavne - jak tento pripad poresit jinak, nez periodicky z cronu 
ntpd restartovat?
Nevedel by nekdo zdejsi, jak ntpd primluvit k tomu, aby k tomu bud 
nedochazelo, nebo abych o tomto stavu byl alespon dostatecne informovan? 
(e-mailovy daily report z hlasky v syslogu messages, nebo tak neco)

[...]

Mirek