Rorschach gibt heute den Tipp Uhrzeit mit cron.daily und ntpd auf dem neusten Stand halten. Von diesem Tipp möchte ich abraten… Ich zitiere mal ntpdate from cron — DON’T DO THAT!: „Contrary to what you may have heard, ntpdate does not keep your system clock synced. Also ignore the foolish recommendations to run ntpdate from a cron job.“ Wie auch die manpage von ntpdate eher empfiehlt den ntpd zu benutzen: „However, it is important to note that ntpdate with contrived cron scripts is no substitute for the NTP daemon, which uses sophisticated algorithms to maximize accuracy and reliability while minimizing resource use. Finally, since ntpdate does not discipline the host clock frequency as does ntpd, the accuracy using ntpdate is limited.“
Selbst der Autor von ntpdate rät vom Einsatz von ntpdate und Cron für diese Aufgabe ab. Warum sollte man nicht ntpdate über Cron nutzen, sondern einen Time-Server wie ntp? ntpdate aktualisiert die Uhrzeit auf einen Schlag. Geht die Systemzeit 10 Minuten vor und man ruft ntpdate auf, so ist es auf dem System sofort 10 Minuten „früher“.
Was ist daran schlimm? Nur um ein triviales Beispiel zu nennen. Ein Linux schreibt viele Logdateien. Wird die Uhrzeit nun auf einen Schlag um 10 Minuten nach hinten gestellt, so gibt es auf einmal Logeinträge die zur selben Uhrzeit erstellt wurden, aber eigentlich 10 Minuten auseinander liegen. Oder es gibt Prozesse, die eine Authentifizierung für eine gewisse Zeit erlauben, ein schlagartiges Ändern der Zeit kann hier problematisch werden, weil diese Authentifizierung auf einmal ablaufen. Daher ist der Einsatz von ntpdate und Cron ganz speziell auf Servern eine wirklich schlechte Idee.
Was macht ntpd nun anders? ntpd korrigiert die Zeit des Systems allmählich. Geht die Systemuhr nach, so wird sie etwas beschleunigt, geht die Zeit vor, so wird sie gebremst. Die geschieht schleichend, so dass im System nichts durcheinander gebracht wird. Des weiteren lernt ntpd wie die Systemuhr falsch geht und korrigiert sie so automatisch. Wie lässt man nun den Rechner über ntpd korrekt seine Zeit stellen? Dazu muss nur das Paket ntpd installiert werden…
$ sudo apt-get install ntp
Anschließend sollte man noch einen Zeitserver in der eigenen Umgebung einstellen. Von Haus aus benutzt Ubuntu bspw. den Zeitserver ntp.ubuntu.com. Um die Latenzzeit zu verbessern, sollte man in der /etc/ntp.conf daher bspw.
server ntps1-0.cs.tu-berlin.de server ntps1-1.cs.tu-berlin.de
eintragen, um die Zeitserver der TU-Berlin zu benutzen. Damit diese Änderung aktiv wird muss letztendlich noch der Dienst neu gestartet werden.
$ sudo /etc/init.d/ntp restart
Alternativ bietet GNOME die automatische Installation des ntpd-Dienstes an. Man öffnet einfach System | Systemverwaltung | Datum und Uhrzeit aus und wählt die Option Synchronisierung mit Internet-Servern aufrecht erhalten aus. Danach wird automatisch ntp installiert.
Ruf man den Dialog anschließend nochmal auf, so kann man über eine graphische Oberfläche bequem und einfach die zu benutzenden Zeitserver auswählen.
Danke, dass ich nicht der einzige bin, der sich immer den Mund fusselig redet, dass ntpdate und cron keine wirklich geeigneten Kandidaten für eine kontinuierliche Zeitsynchronisation sind.
Jetzt fehlt bei Dir nur noch der Hinweis auf pool.ntp.org, um die wirklich wichtigen Stratum 0 Zeitserver zu entlasten.
Hi Chrisss,
erstmal danke für den Hinweis! Dessen war ich mir nicht bewusst.
Ich denke der Impact dürfte aber doch relativ gering sein oder? Wenn ich jeden Tag diese Skript über einen cronjob ausführe sollten solche 10min Differenzen eigentlich nicht auftreten. Selbst eine Sekunde wäre schon sehr sehr merkwürdig.
Anders müsste ich ständig einen ntpd laufen lassen und der Atom-Prozessor meines Rechners ist so schon meist am glühen.
Ich werd mir jetzt mal überlegen ob ich das weiter so machen werden.
grüsse
Ich hab schon darauf gewartet, daß sich jemand mit der besseren Alternative äußert 😉
@Rohrschach, soviele Ressourcen bracht ntpd nicht. Selbst ein P1 würde sich da noch langweilen …
Ich bedanke mich für die Hinweise und die ausführlichen Erläuterungen. Ich war etwas verunsichert betreffs der Rohrschachhinweise.
Mit freundlichen Grüßen
Wolfgang
Hmm… mach ich was falsch? Das packet scheint es unter 8.04server nich zu geben:
root@host:~# apt-get install ntpd
Paketlisten werden gelesen… Fertig
Abhängigkeitsbaum wird aufgebaut
Reading state information… Fertig
E: Konnte Paket ntpd nicht finden
Danke für die Erläuterungen, ich hatte mir da auch ein Cron-Script für gemacht 🙂
Das Paket heißt ntp, sowohl unter Debian als auch Ubuntu (Aber der Dienst heißt ntpd)
@rUMPel
Sorry, hatte einen Fehler im Artikel. Das zu installierende Paket nennt sich ntp, der Dienst ntpd… Habs im Artikel ausgebessert.
Was passiert eigentlich wenn ne Zeitumstellung zwischen Winter- und Sommerzeit ansteht? Bzw. umgekehrt. Die Zeit vorstellen kann ich ja verstehen aber so ne ganze Std zurückstellen ist doch sicher nicht so gut.
> Was passiert eigentlich wenn ne Zeitumstellung zwischen Winter- und Sommerzeit ansteht? Bzw. umgekehrt. Die Zeit vorstellen kann ich ja verstehen aber so ne ganze Std zurückstellen ist doch sicher nicht so gut.
Nix, die interne Uhr läuft ja mit UTC. Wenn ein Programm aber nicht auf sowas eingestellt ist, kanns natürlich Probleme geben.
Wird ntpdate bei der Installation von ntp stillgelegt? Nicht, dass zwei konkurrierende Prozesse gegeneinander arbeiten.
Sicherheitshalber könnte man ja ntpdate deinstallieren. Macht das Sinn?
> Wird ntpdate bei der Installation von ntp stillgelegt?
Nein.
> Nicht, dass zwei konkurrierende Prozesse gegeneinander arbeiten.
ntpd ist ein Dienst, läuft also immer im Hintergrund. ntpdate ist ein Programm, das nur bei Bedarf gestartet wird.
> Sicherheitshalber könnte man ja ntpdate deinstallieren. Macht das Sinn?
Nein.
Ich hab vor kurzem mal wieder ein Ubuntu auf meinem Rechner installiert und nach ner Weile mitbekommen dass die Systemuhr um eine halbe Stunde aus dem Ruder läuft. Nun ist ntp aber installiert und ntpd läuft auch ordnungsgemäß… Die Systemuhr geht übrigens nicht so extrem falsch (in 8 Stunden knapp 9 Minuten) was für mich also heißt dass ntp da irgendwas in die falsche Richtung korrigiert…
Irgendeine Idee warum dem so ist?
Kleines Update: Die Hardwareuhr (ermittelt mit hwclock) läuft bestens und richtig, die Systemuhr (über date) läuft falsch…
ntp ist also doch nicht schuld…
Nur wieso geht die Systemuhr so falsch? Momentan behelfe ich mir mit einem minütlichen Abgleich (bei ausgeschaltetem ntpd, denn der kann ja eh nur 1s pro 2000 sekunden drift korrigieren) aber das ist nur eine „Frickellösung“ die ich so eigentlich nicht lassen will…
Hallo Stefan, hmmmm… Wenn an meinen Rechner die Uhr so falsch lief, dann lag es eigentlich meist an der BIOS-Batterie des Rechners. Wie alt ist denn der Rechner?
Mhm der ist jetzt um die 3 Jahre alt, allerdings läuft die Hardwareuhr ja richtig, nur der Teil der von „date“ angesprochen wird ist total falsch…
Ich hab jetzt schon einen cronjob drinnen der jede Minute „hwclock –hctosys“ aufruft, aber da ist ja das gleiche zu beachten wie bei „ntpdate“ 😉
*an den Kopf fass* Problem gelöst: nach der Installation von „adjtimex“ läuft die Systemuhr wieder so wie es die Hardwareuhr tut, unterstützt von ntpd ist nun die PC-Uhr die genauste in meinem Haushalt 😉
Danke für die Hilfe und auch den Post an sich, hab wiedermal einiges gelernt 🙂
Hi, sorry dass ich dir da nicht helfen konnte. Solch eine bockige Hardware-Uhr hatte ich noch nicht vor mir. adjtimex hört sich nach dem richtigen Paket für diese Aufgabe an. Eventuell hätte man das auch mit einem Cronjob und ntpdate fixen können.
Hehe, bockig könnte man meinen Rechner manchmal nennen, das stimmt 😀
Aber wie gesagt die Hardwareuhr läuft genau so wie sie soll, nur die Linuxzeit wollte nicht so wie sie sollte 😉
Das Paket gibt einem im Grunde die Funktionalität des Systemcalls „adjtime“ als Konsolenprogramm. Es macht also das Gleiche wie „ntpd“, allerdings geht es nicht so zimperlich vor wie ntp, und man kann so die ticks und frequency erstmal grundanpassen. Nun hoffe ich ntp verreißt mir die Werte nicht gleich wieder 😀
Das ganze „Ntpdate nicht als Cron-Job“-Gerede vernachlässigt meiner Meinung nach, dass es sich hier um ein Trade-Off handelt. In manchen Situation will ich einfach nicht, dass die Zeit kontinuierlich angepasst wird. Z.B. wenn mir wichtig ist, dass eine Minute Systemzeit wirklich eine Minute in Realität ähnelt. Ein Sprung ist einfacher zu erkennen und zu korrigieren, als eine allmähliche Verzehrung. Eingebettete Systeme haben heute oft genau dieses Problem. Außerdem haben sie nach dem Booten oft keine Ahnung welcher Tag heute ist und NTPd braucht zwei Tage um die Zeit richtig einzustellen, wenn ein dürftiger Wireless-Link auf dem Weg zum NTP-Server liegt. NTPd ist heutzutage nicht vielseitig genug…