Einmalig: ntpdate aurufen. Weiss grad nicht ob das per
/etc/init.d/sonstwas automatisch geschieht.
Permanent: ntp installieren, läuft dann automatisch als Service, und
ggf. /etc/ntp.conf einstellen. Nach Start 10min warten, es dauert etwas
bis stabiler Status per "ntpq -p".
Obacht: NTP synced nur, wenn die Zeit schon vorher einigermassen passt,
auf ein paar Minuten oder so. Also ggf. ntp runterfahren, mit ntpdate
Zeit einstellen, dann ntp hochfahren. Dann bleibt sie in sync.
Ich hab noch ein anderes Problem. Ich habe die Hardwareuhr gesetzt mit
hwclock --localtime --set --date="9/24/2010 17:47:00"
In /etc/adjtime stand danach in der letzten Zeile LOCAL.
Dann hab ich die Hütte rebootet und die RTC im BIOS angesehen und dort
lief sie noch/wieder auf UTC. Offenbar gibts da noch irgendwo eine
konkurrierende Einstellung.
> Obacht: NTP synced nur, wenn die Zeit schon vorher einigermassen passt,
Ja, das war mir früher schonmal aufgefallen. Das gibt insbesondere dann
Ärger, wenn die RTC auf Local Time läuft und die Zeit umgestellt wird.
Irgendwo bei ntp gibts da ein Schräubchen, wenn man das auf 65 min
stellt, dann gehts.
Uhu Uhuhu schrieb:> hwclock --localtime --set --date="9/24/2010 17:47:00"
Das setzt zwar die Hardwareuhr, nicht aber die Linux-Uhr. Im Shutdown
wird evtl. automatisch ein hwclock durchgeführt, --systohc oder so, d.h.
deine Änderung wird dann überschrieben.
Besser: Mit date oder ntpdate die Linux-Uhr setzen, dann
hwclock --systohc
Es kann auch sein, dass UTC/localtime noch woanders definiert wird. Im
Ubuntu beispielsweise in /etc/default/rcS, woraus vmtl. der hwclock
Aufruf abgeleitet wird.
Uhu Uhuhu schrieb:> Hm, ntpdate meint: ntpdate[2390]: no servers can be used, exiting> In /etc/ntp.conf sind zwei Server eingetragen.
Tja, muss ich das Englisch wirklich übersetzen? Ein Server der nicht
servt ist kein Server. Man kann ntpdate auch mit Parameter aufrufen.
Hab grad kein lenny parat, aber beim VDR (etch Basis) steht die Liste
für /etc/init.d/ntpdate in /etc/default/ntpdate.
Na ja, übersetzen kann ich mir das auch, aber die Formulierung ist nicht
gerade sonderlich präzise. In der ntp.conf sind insgesamt 6 Server
aufgeführt.
Aha:
ntpdate ntpa2.kph.uni-mainz.de
gibt ein etwas anderes Ergebnis:
ntpdate[2404]: the NTP socket is in use, exiting
Jetzt stellt sich natürlich die Frage, warum das so ist.
Warum werde ich oben wohl ausdrücklich geschrieben haben, dass du den
"ntp" runterfahren solltest, bevor du "ntpdate" aufrufst? Es kann nur
einen geben. Also:
/etc/init.d/ntp stop
..ggf. bischen warten bis Port frei..
ntpdate suchdirwasaus
/etc/init.d/ntp start
Es bleibt mysteriös: Zumindest der letzt Server in meiner ntp.conf
ntps1-2.uni-erlangen.de antwortet und ntpdate setzt die Zeit.
Die Debian-Server, die sowohl in /etc/ntp.conf, als auch
/etc/default/ntpdate eingetragen sind, gehen auch, wenn ich sie auf der
Kommandozeile für ntpdate angebe. ntpdate ohne Parameter antwortet mit
ntpdate[2461]: no servers can be used, exiting
Eine Fehlerliste fehlt in /etc/default/ntpdate
Uhu Uhuhu schrieb:> In welcher Konfigurationsdatei ist hinterlegt, ob die RTC auf UTC, oder> Local Time läuft? Kann man das nachträglich umsetzen?
1
man 5 rcS
--> nach "UTC" suchen.
Wenn der Rechner aber ausschliesslich für Linux genutzt wird, ist es
empfehlenswert, die RTC auf UTC laufen zu lassen. Da gibt es dann auch
garantiert keine Probleme mit Sommer-/Winterzeitumstellung, da UTC diese
natürlich nicht kennt.
Die Linux-Systemuhr selbst läuft sowieso weder auf Localtime noch auf
UTC. Stattdessen ist die Unix-Zeit (Zahl der Sekunden seit dem 1.1.1970)
das Maß aller Dinge. NTP wiederum arbeitet immer mit UTC.
Wenn ein Programm Localtime verlangt, wird on the fly aus der Unixzeit
anhand der Zeitzoneninformationen die korrekte Zeit berechnet, unter
Berücksichtigung von Sommer-/Winterzeit, Schaltsekunden und allem
Pipapo.
Dementsprechend leicht ist es auch, mal eben nachzusehen, wie die
Uhrzeit in einer anderen Zeitzone gerade ist:
1
% date
2
Fri Sep 24 19:24:04 CEST 2010
3
% TZ=EST date
4
Fri Sep 24 12:24:05 EST 2010
(EST=Eastern Standard Time, Ostküste USA)
> ntpdate ohne Parameter antwortet mit>> ntpdate[2461]: no servers can be used, exiting
ntpdate schaut nicht selbst in /etc/default/ntpdate, das wird vom
Init-Script gemacht (/etc/init.d/ntpdate), und ntpdate dann mit den
Servern als Parameter aufgerufen.
Rufst du ntpdate von Hand auf, musst du schon die Server selbst auf der
Kommandozeile angeben. In Verbindung mit einem der Parameter "-v"
(verbose) bzw. "-d" (debug) zeigt dir ntpdate dann auch detailliert an,
was mit den einzelnen Servern los ist. Oder du rufst das Init-Script
auf:
Andreas Ferber schrieb:> Da gibt es dann auch> garantiert keine Probleme mit Sommer-/Winterzeitumstellung, da UTC diese> natürlich nicht kennt.
Doch die gibts in meinem Fall genau dann:
Der Rechner soll per RTC gestartet werden. Wenn die Lokalzeit
umgeschaltet wird, geht das um eine Stunde falsch. Da er am Wochenende
nichts machen soll, macht die Verschiebung, die es Sonntags nach der
Zeitumstellung gibt, nichts; Hauptsache, die RTC wird dann auf ntp-Zeit
gesetzt, dann stimmts wieder.
Zudem gibt es Kuddelmuddel mit Windowsrechnern im LAN, wenn die
Linux-Maschinen auf UTC ticken - oder es war mal so, falls das jetzt
gefixt ist.
Aber danke für den Tipp mit /etc/default/rcS - das war der Knoten.
Uhu Uhuhu schrieb:> Zudem gibt es Kuddelmuddel mit Windowsrechnern im LAN, wenn die> Linux-Maschinen auf UTC ticken
Nur wenn du auf der gleichen Maschine wahlweise Windows und Linux
bootest. Ob die RTC auf UTC oder lokaler Zeit steht ist nach der
Zeitübernahme beim Start vollkommen egal.
A. K. schrieb:> Nur wenn du auf der gleichen Maschine wahlweise Windows und Linux> bootest.
Nein. Du kriegst auch Probleme mit dem Änderungsdatum, wenn du Dateien
zwischen einer Linux-Maschine, die auf UTC läuft und einer
Windowsmaschine hin und her kopierst. Das hopst dann um den Offset auf
UTC - obs noch so ist, weiß ich nicht, aber es war zumindest mal so.
Uhu Uhuhu schrieb:> Nein. Du kriegst auch Probleme mit dem Änderungsdatum, wenn du Dateien> zwischen einer Linux-Maschine, die auf UTC läuft
Das hat reinweg garnichts mit der RTC zu tun. Wie Andreas oben schon
schrieb läuft ein korrekt konfiguriertes Linux (wie Unix) intern
weltweit immer auf die gleiche Art, nämlich in Sekunden ab 1970 in
UTC-Zeitzone. Ganz egal ob die RTC auf UTC oder lokaler Zeit steht.
Irgendwelche lokale Zeit entsteht ausschliesslich durch Umrechnung
dieser internen Zeit.
Die RTC wird ausschliesslich dazu verwendet, ein startendes Linux
einmalig mit der Zeit zu versorgen. Danach hat die RTC für das laufende
System keinerlei Bedeutung mehr. Freilich hängt diese einmalige
Einstellung davon ab, ob die RTC auf UTC läuft, weil das System ggf.
eine lokale Zeit der RTC in die mit UTC Zeitzone arbeitende interne Zeit
umrechnen muss.
Wenn also Probleme im Netzwerk auftreten, dann hat das mit Sicherheit
nicht mit der Einstellung der RTC zu tun. Sondern mit einer
Fehlkonfiguration. Beispielsweise indem man dem Linux sagt, die RTC
liefe auf UTC während sie auf lokaler Zeit läuft, und zum "Ausgleich"
die Zeitzone des Systems als UTC spezifiziert, obwohl man nicht in
englischer Zeit lebt. Dann stimmt zwar scheinbar zunächst alles, weil
die Uhrzeit korrekt angezeigt wird, aber tatsächlich hat man das System
verarscht und es rächt sich auf seine Weise.
Ich kann nur sagen, daß Samba genau dann keine Zicken gemacht hat, wenn
ich bei der Installation alles auf Local Time eingestellt hatte.
Es kann natürlich sein, daß die Maschine dann insgeheim auf UTC lief. Es
war jedenfalls bevor ich die Zeit per ntp bezogen habe und so fiel das
nicht auf.
Aber einerlei. Das maßgebliche Argument heute ist das, was ich oben im
Zusammenhang mit dem Start per RTC geschrieben habe.
Neue Klippe: Der Rechnerstart über BIOS gesteuert von der RTC
funktioniert plötzlich nicht mehr. Mit DSL auf der Platte hatte es noch
prima funktioniert.
Dasselbe Problem habe ich auf relativ modernen Rechner, auf dem Ubuntu
läuft. Obs bei dem jemals funktioniert hat, weiß ich nicht, denn es lief
nie was anderes, als Ubuntu drauf.
Liegt das womöglich daran, daß ntp sich beim runterfahren an der RTC zu
schaffen macht?
[Hinweis an die Windows-User: Diese Funktion hat nichts mit der
Windows-Funktion zu tun, die den Rechner timergesteuert hochfährt! Die
setzt nämlich bei Windows voraus, daß die Maschine nicht power down ist,
sondern im hibernate.
Also liebe Windows-Freunde: Das hier ist definitiv was anderes!]
