In welcher Konfigurationsdatei ist hinterlegt, ob die RTC auf UTC, oder Local Time läuft? Kann man das nachträglich umsetzen?
Danke! Und wo muß man auf einem Kommandozeilensystem drehen, daß die Systemzeit per NTP geholt wird?
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".
Ja, ntp habe ich installiert und Server in /etc/ntp.conf eingetragen. Mal sehen, obs funktioniert.
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.
Hm, ntpdate meint: ntpdate[2390]: no servers can be used, exiting In /etc/ntp.conf sind zwei Server eingetragen.
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
Um zu überprüfen mit welchen servern der lokale ntp daemon Kontakt hält, kannst Du ntpq aufrufen; dort dann den Befehl peers verwenden.
ntpq -p zählt alle 6 Server auf, nachdem ich ntp wieder gestartet hatte. 5 davon antworten.
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:
1 | /etc/init.d/ntpdate start |
Andreas
Es ist wie verhext: Egal, was ich anstelle, beim nächsten Boot steht die RTC wieder auf UTC.
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.
Uhu Uhuhu schrieb: > Aber danke für den Tipp mit /etc/default/rcS - das war der Knoten. Hättest du auch schneller haben können => 17:58 :)
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!]
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.