Debian 7.7 als Zeitserver - Restart erforderlich

[SVblue]

Hallo,

ich habe hier zwei identische Debian 7.7 Installationen.
Beide sollen für weitere Rechner (Raspberrys) die aktuelle Zeit zur Verfügung stellen.
Wird bspw. ein Raspberry gestartet so soll er sich gleich die aktuelle Zeit von einem der Server holen. (Die Raspberrys sind jeweils nur einem Debian-Zeitserver zugeordnet.)

Die Raspberrys die Debian-Server-1 zugeordnet sind bekommen ohne zu murren die Zeit vom Server sobald sie gestartet werden.
Andere Raspberrys, die dem Debian-Server-2 zugeordnet sind scheitern leider. Erst wenn ich am Server-2 die ntp-Dienst via "/etc/init.d/ntp restart" quasi manuell neu starte erhalten auch sie die richtige Zeit.

Auf beiden Servern startet der ntp-Dienst automatisch beim Booten. Bei beiden wird der Dienst auch unter den laufenden Prozessen gelistet ("top"), aber nur Server-2 benötigt dennoch einen Restart des Dienstes nach dem Booten. Ein zusätzlicher Eintrag in die rc.local brachte auch keinen Erfolg.

Was kann das sein? Wo liegt der/mein Fehler?

[dufty2]

Willkommen im Forum!

Mmmh, hört sich etwas seltsam an.
Welchen NTP-Server hast Du instaliert?
Den "ganz normalen", sprich das Paket "ntp"?

Kann Du mal "ntpq -np" auf beiden Zeitservern ausführen (bevor die raspi-client zugreifen)?
Und die Ausgabe posten?

[SVblue]

Installiert ist das ganz normale ntp-Paket, ohne weitere Konfiguration in der ntp.conf


... die restlichen Angaben folgen.

[SVblue]

ntpq -np
gibt nun folgendes aus:

Server-1 (im laufenden Betrieb):

Code: Alles auswählen

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 212.18.3.18     212.18.1.106     2 u 103m 1024   40   19.691   -0.143   0.000
+129.250.35.251  192.93.2.20      2 u 102m 1024   40   37.484    6.339   0.140
+5.9.111.80      131.188.3.223    2 u 102m 1024   40   21.790    0.831   0.145
*46.235.112.25   129.69.1.153     2 u  649 1024   51   19.852   -2.319   3.620

Server-2 (nach reboot):

Code: Alles auswählen

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*129.70.132.37   129.70.130.71    2 u   31   64   17   19.516    1.515   0.366
+188.138.90.201  188.174.253.163  3 u   31   64   17   22.663    0.674   0.720
-46.4.24.238     131.188.3.220    2 u   34   64   17   73.812   22.125  24.676
+5.45.97.110     131.188.3.220    2 u   33   64   17   35.324    7.895   6.850

[SVblue]

OK, ich habe nun bemerkt, dass wenn der Server-2 mehrere Minuten läuft, ein restart des ntp-Dienstes nicht erforderlich ist.
Leider hilft mir das nicht weiter. Mit dem Start des Servers starten auch die Raspberrys und benötigen dann auch die aktuelle Zeit+Datum. Offenbar gibt's hier eine Art Delay... nur wo?

[dufty2]

Wenn ich's noch richtig im Kopf, dann gibt ein ntp-server erst dann die Zeit an seine ntp-clients weiter, wenn er sich sich selbst zu seinen ntp-server synchronisiert hat. Das erreichte Synchronisieren sieht man am Sternchen "*" bei der "ntpq -np"-Ausgabe.
Deshalb hat man auch 2 ntp-server eingetragen, falls mal einer rebootet.
Nun sind zwei ntp-server (für einen ntp-client) auch schlecht, weil der ntp-client kein sog. quorum bilden kann,
also den auswählen, an den er sich synchronisieren will (das Sternchen "*").
Also braucht man 3. Aus mir nicht ersichtlichen Gründen kann bei 3 auch noch kein Quorum gebildet werden,
also trägt somit in der Regel 4 verschiedene ntp-server in der /etc/ntp.conf bei einem Client ein.

Evtl. kannst Du jeweils eine zusätzliche virtuelle IP (eth0:1) pro Server auflegen und so den raspi-clients 4 ntp-server "unterjubeln".
Weiss aber nicht, ob ntp das rausbekommt, dass 2 davon nur "virtuell" sind.

Abgesehen davon ist die Synchronisation Deiner 2 Server suboptimal.
Zum Vergleich ein client aus einem Intranet:

$ ntpq -np
remote refid st t when poll reach delay offset jitter
==============================================================================
+10.0.0.4 10.0.0.41 2 u 42 1024 377 0.610 -0.165 0.588
+10.0.0.5 10.0.0.41 2 u 981 1024 377 0.641 -0.207 0.871
+10.0.0.6 10.0.0.41 2 u 885 1024 377 0.524 0.020 0.618
*10.0.0.7 10.0.1.60 2 u 404 1024 377 1.077 -0.325 0.530

Man sieht, die reach(ability) ist 377 (optimal), bei Dir nur "40",
dewsweiteren werden die 4 Server alle 1024 Sekunden abgefragt (when), Du hingegen hast Werte von
102m(inuten), d. h. den externen ntp-server seit fast zwei Stunden nicht mehr erreicht.

Klar, wenn man übers Internet synchronisiert, bekommt man keine Superergebnisse.

[SVblue]

Danke. Ich werde dann mal noch andere Zeitserver ausprobieren.
Prio A wäre für mich dass die Raspberrys eine brauchbare Zeitangabe bekommen da sie selbst keine Uhr besitzen. Ob die Zeit am Server so ganz genau ist wäre mir nicht ganz so wichtig, er hat schließlich eine "Uhr" mit Batterie.

[Livingston]

Zum Booten empfiehlt sich einmalig ntpdate. Da wird nicht lange gefackelt, sondern die Zeit sofort neu gesetzt.