NTPD verküppelt warum

ath0

Well-Known Member
Hallo,

ich habe gerade wieder ein FreeBSD installiert, dabei installiere ich eigentlich immer openntpd.
Der NTPD aus dem base system verabschiedet sich regelmäßig (oder hat er in der vergangenheit).

Jetzt stelle ich mir die Frage warum der verkrüppelte NTPD, der angeblich performanter gemacht worden sein soll und deswegen so kaputt ist z.b. kurze Netzaussetzer können ihn schon zum schweigen bringen, im Basis system ist und nicht openntpd.
Wer ist daran interessiert ein schnelles instabieles Program zu haben anstelle eines normal schnellem stabielen Programs? Irgendwie leutet mir das nicht ein ... außer da war einer von den Linux kiddys bei XD

Hat da einer mehr hintergrund wissen was das erklären würde?
 
Der "offizielle" ntpd ist im Basissystem, da unter den FreeBSD-Entwicklern mehrere Time Keeping Nerds sind und sie gern das volle Feature Set haben möchten. openntpd, systemd-timesyncd und die meisten anderen alternativen Implementierungen haben nur einen Bruchteil der Features. Die reichen zwar für meisten Nutzer vollkommen aus, aber eben nicht für alle... Der miserable Zustand des ntpd ist allerdings auch Upstream bei seinen Entwicklern angekommen, weshalb Poul-Henning Kamp an einem Nachfolger arbeitet. Den werden sicher früher oder später auch in FreeBSD sehen.

Davon einmal abgesehen, zwei Punkte die das Problem eventuell lösen können:
  • Man sollte 'ntpd_sync_on_start="YES"' in der /etc/rc.conf haben. Denn sonst steigt der Dienst bei zu hoher Abweichung sofort aus. Läuft, macht aber nichts.
  • Der Drift (nach ~30 Minuten in /var/db/ntpd.drift) muss unter 500 liegen. Sonst erklärt ntpd die Uhr für kaputt und steigt aus. In dem Fall muss man die Timecounter erstmal manuell einschwingen.
 
Das bedeutet, der Nachfolger soll alle featurs haben aber stabiler sein ja? Sonst könnte man ja auch openntpd in base einbauen.
Davon einmal abgesehen, zwei Punkte die das Problem eventuell lösen können:
  • Man sollte 'ntpd_sync_on_start="YES"' in der /etc/rc.conf haben. Denn sonst steigt der Dienst bei zu hoher Abweichung sofort aus. Läuft, macht aber nichts.
  • Der Drift (nach ~30 Minuten in /var/db/ntpd.drift) muss unter 500 liegen. Sonst erklärt ntpd die Uhr für kaputt und steigt aus. In dem Fall muss man die Timecounter erstmal manuell einschwingen.

Ja die "Probleme" hat openntpd ja auch aber da gibt es ja nen Parameter für ( -s ). Beim Offiziellen ist das auch nicht das Problem, eher dass er im Falle eines tempoären ausfall der Internet Verbindung bis zum neustart den Geist auf gibt. War mir damals auf nem Laptop aufgefallen (ohne Netz gestartet aber dann mit Netz gearbeitet), das hatte mich weniger gestört, bei mein Mailserver hatte er den Dienst quitiert nach dem mein Provider einen Ausfall wegen gekappter Kabel hatte. Openntpd läuft aber in solchen fällen wie ne Eins.
Anscheinend gibt es dann nicht wirklich eine richtig plausible Erklärung für den crapy NTPD. War nur ne Frage die mir beim Aufsetzen so durch den Kopf ging, nichts was mich richtig stört.
 
Bei mir ist ntpdate aktiviert was ja erst mal die Uhr grob synchonisieren soll. Anschließend übernimmt ntpd:

Code:
~% rcorder /etc/rc.d/* | cat -n | grep ntp
    64  /etc/rc.d/ntpdate
   124  /etc/rc.d/ntpd

Was spricht dagegen?
 
Ich kann das Problem mit ntpd übrigens nicht nachvollziehen. Bei mir läuft das auf dem Laptop einwandfrei obwohl mein Laptop viel Zeit in einem verbarrikadierten Netz verbringt in dem er keine Server erreichen kann.
 
Ich würde mir bei openntpd nicht so sicher sein, dass er nicht aussteigt (und weiter läuft!). Bei openntpd kann ich nicht einsehen, ob und mit welchen Servern das Teil synchronisiert (jedenfalls kenne ich nichts dazu). Ich sehe in den Logs nur verworfene Server und dann irgendwann gar keine Meldungen mehr (keine Ahnung, ob er sie später wieder kontaktiert oder nicht). Ich habe jetzt openntpd am Laufen auf allen meinen Kisten, aber einfachste Features hat es nicht... und zwar essentielle(!) Features.

Ich hatte früher das Problem, dass ich openntpd installiert habe und nach einem Monat war die Uhr einfach falsch (openntpd konnte sie nie einstellen, weil es an irgendeinem syscall gescheitert ist), aber fröhlich weiter lief. Ich traue dem Braten nicht so.

Ich glaube, ich wechsle wieder bei Gelegenheit zurück zu ntpd. Es mag grottig sein, aber es hat alles was ich brauche.
 
Das bedeutet, der Nachfolger soll alle featurs haben aber stabiler sein ja? Sonst könnte man ja auch openntpd in base einbauen.
Poul-Henning Kamp's Neu-Implementation Ntimed besteht aus mehreren, separaten Teilen. Die meisten werden ausschließlich den Ntimed client nutzen - er synchronisiert den Rechner mit einem Time-Server aus dem lokalen oder Inter-Net. Dafür werden dann statt einigen hunderttausend Zeilen Code des derzeitgen NTPD nur noch unter 10.000 benötigt. Das klingt schon mal sehr gut, weil schlank und sicher ziemlich stabil.

Wer seinen eigenen Time-Server im z.B. lokalen Netz betreiben will, wird den Ntimed Slave nutzen.

Und die (wenigen) Forschungs- und ähnlichen Einrichtungen, die ihre eigenen Atom-Uhren betreiben, nutzen Ntimed Master. Der normalsterbliche Admin wird dieses Programm wohl nie verwenden.

Sehr gute Notizen von PHK's Ntimed Präsentation auf der FOSDEM 2015 Anfang Februar, gibt es von Mattias Geniar (in Englisch).

Auf OpenNTPD angesprochen, meinte PHK übrigens, dass er den Code sehr gut fand und dass - wem das beschränkte Featureset ausreiche - man diesen ruhig nutzen solle. Allerdings fügte er noch einen kleinen Seitenhieb gegen die OpenBSD'ler hinzu, die seiner Meinung nach oft tolle Tools entwickelten, diese dann aber nicht weiter pflegten (so war z.B. die portable Version von OpenNTPD eine ganze Zeitlang ohne Maintainer).
 
Bei mir ist ntpdate aktiviert was ja erst mal die Uhr grob synchonisieren soll. Anschließend übernimmt ntpd:

Code:
~% rcorder /etc/rc.d/* | cat -n | grep ntp
    64  /etc/rc.d/ntpdate
   124  /etc/rc.d/ntpd

Was spricht dagegen?
Spaulding, das ist ganz einfach, die Mimik gilt halt nur für den Neustart, wenn aber mittendrin ntpd für längere Zeit keine Verbindung hat - aus welchem Grund auch immer - dann stellt jener die Synchronisation ein. Insofern ist ntpdate nur ein Mosaiksteinchen im Gesamtbild.
 
ntpdate brauchst du gar nicht. "sysrc ntpd_sync_on_start=YES" lässt ntpd beim Starten die Zeit unabhängig von aktuellen Zeitdelta setzen -- genau das, was ntpdate macht.
 
Ich würde mir bei openntpd nicht so sicher sein, dass er nicht aussteigt (und weiter läuft!). Bei openntpd kann ich nicht einsehen, ob und mit welchen Servern das Teil synchronisiert (jedenfalls kenne ich nichts dazu). Ich sehe in den Logs nur verworfene Server und dann irgendwann gar keine Meldungen mehr (keine Ahnung, ob er sie später wieder kontaktiert oder nicht).

Ich hatte das Problem mit openntpd noch nicht, mit ntpd aber schon. Das es nicht noch passieren kann möchte ich nicht behaupten und ich möchte auch nicht sagen das openntpd besser ist als ntpd. Ich habe nur meine Erfahrungen damit gemacht (ok, die sind auch schon ca 4 Jahre her) und habe die instabilität gespürt. Welche Funktionen ein ntpd noch so haben sollte weiß ich nicht, da ich das ding nur zum Zeit synchronisieren nutze mehr brauche ich nicht. Welchen Server das ding benutzt ist mir relativ Wurst und solte ich es doch mal wissen wollen, schaue ich mit nem sniffer oder lassem mir was anderes einfallen.

Sobald ntimed in der base ist, werde ich auch diesem Programm seine chance geben und es ausprobieren. Ich habe nicht viele Ansprüche an ein Programm, an erster Stelle steht das es zuverlässig funktionieren muss ist der code dann auch noch halbwegs schön und es lässt sich noch gut bedienen bzw. einrichten ... dann bin ich glücklich.Was ja auch der Grund ist, das ich mit FreeBSD im allgemeinen wirklich wunschlos glücklich bin :)

Spaulding, das ist ganz einfach, die Mimik gilt halt nur für den Neustart, wenn aber mittendrin ntpd für längere Zeit keine Verbindung hat - aus welchem Grund auch immer - dann stellt jener die Synchronisation ein. Insofern ist ntpdate nur ein Mosaiksteinchen im Gesamtbild.

Erstmal genau das problem hatte ich! Und zweitens führst du Selbstgespräche? :D
 
Erstmal genau das problem hatte ich! Und zweitens führst du Selbstgespräche? :D
Genau genommen hatte ich das Problem noch nicht im Serverbetrieb, weil eben das Netz weitgehend klaglos arbeitet bzw. Netzwerkprobleme scheinbar nicht all zu lange anhalten, um ntpd aus dem Tritt zu bringen.

Insofern habe ich mich und andere (ich komme nicht hierher, um rhetorische Fragen zu stellen) dann gefragt, wie robust "mein" aktuelles ntpdate/ntpd-Setup denn nun ist. Und da auf die Frage nichts zurück kam, habe ich das Spiel weiter getrieben. Letztendlich hat lmes Antwort mir gezeigt, dass mein Setup bzgl. Deinem Problem nicht zielführend ist.

Insofern ist Dein Problem dann im Fall eines Falles auch nun mein Problem. Dem entgegen wirken kann man dann wie hier ausführlich geschildert mit robusteren Neuimplementierungen. Eine Alternative, die schon viel länger z.B. im Nachbarfred heiß diskutiert wird, ist dann das Monitoren der Funktionstüchtigkeit eines Daemons, einer Prozessgruppe. Was uns bis jetzt z.B. unter FreeBSD zur Verfügung steht, das ist der von NetBSD abstammende fscd oder D. J. Bernsteins daemontools. Da bin ich noch in der Praxisphase was für meinen Zweck sinnvoll ist, bevor ich selbst einen einfachen Watchdog schreibe.

Wie auch immer, das ist nicht der Versuch, Deinen Thread zu hijacken, offtopic zu fahren. Ich gebe mich wieder stickum. Mitlesen reicht mir nun in dem Fall. Danke für Dein Verständnis.
 
Ich benutze ntpd schon garantiert länger als 4 Jahre. Es hat immer anständig funktioniert. Man kann es auch sogar bestätigen, indem man "ntpdc -c peers" anschaut. Bei openntpd ist hier tote Hose, man weiß nur, dass es nicht läuft, wenn die Uhrzeit nach mehreren Monaten 3 Sekunden abweicht. Ich habe jedenfalls nichts gefunden, um ordentliche Funkionstüchtigkeit bei opentntpd nachzuweisen.
 
Das ist nun schon das zweite Mal in diesem Thread, dass du Falschinformationen verbreitest. Für OpenNTPd gibt es ntpctl(8), zwar erst seit OpenBSD 5.5, aber auch davor konnte man mit einem simplen "grep ntpd /var/log/daemon" genügend Informationen bekommen um nachzuvollziehen, "dass es nicht läuft".
 
nakal: Der alten OpenNTPD portable basierte noch einem zuletzt völlig veralteten OpenBSD Relase (4.6). In dieser Version gab es weder eine Anpassung der Taktfrequenz noch eine andere Möglichkeit zur Kontrolle als ein Blick in die Logs. In der aktuellen Version hat OpenNTPD beides. Mittels ntpctl -s all lässt sich der Zustand des Daemons auslesen.
 
Das kannte ich nicht (habe ich ja oben auch gesagt). Ich habe openntpd sofort bei ersten Bekanntgabe ausprobiert, da lief es gar nicht vernünftig. Jetzt habe ich es nur, wegen des langsamen Patchens von ntpd.

pwp: konnte man eben nicht. Wenn nach Monaten die Uhr um 3 Sekunden falsch geht und der Daemon weiter läuft, dann ist das Teil einfach kaputt.
 
Zurück
Oben