guy.brush™ schrieb
Kann mir jemand helfen, woran das liegen könnte? Ich würde es gerne einmal haben, dass meine PCs sich endlich einmal automatisch synchronisieren bei der Uhrumstellung.
Hier noch ein paar Informationen:
Ich habe parallel Windows XP installiert, seit einiger Zeit aber nicht mehr gestartet. Als WM nutze ich KDE.
Zum einen:
dein ntpd -qg schlug fehl, da der/ein ntp-Daemon schon lief. Also entweder als DAEMON in der rc.conf oder manuell starten. Das sagte dir die Fehlermeldung: " unable to bind to wildcard address 0.0.0.0 - another process may be running - EXITING"
Generell:
Für die Umstellung Sommer-/Winter-Zeit braucht es keinen ntpd oder ähnliches. Das passiert automatisch sofern solche Unterschiede in der aktuellen Zeitzonen-Datei (hier: Europe/Berlin) definiert sind.
Selbst mein zur Umstellungszeit schlafender/suspended Laptop hatte nach dem Aufwachen die korrekte Zeitzone, nämlich CET statt CEST.
Ich hole mal etwas weiter aus zum Verständnis:
Die einzige Uhrzeit-Information, die dem PC und einem startenden Betriebssystem anfangs zur Verfügung steht ist die BIOS-Uhrzeit/Datum. Der große Nnachteil daran (wie mit vielem im BIOS) ist: diese Werte geben keinerlei Hinweise auf: ist es die lokale Uhrzeit (wo ich mich gerade aufhalte), ist diese Zeit nun z.B. für DE jetzt Winter- oder Sommerzeit, ist die Zeit lokal oder nach UTC gestellt?
Das stellt Betriebssysteme jetzt vor eine Reihe von Problemen: Es muß wissen: Ist die Uhrzeit lokal (hier in DE also z.Zt. CET, in Lissabon z.B. WET(1 Stunde früher)) oder ist die BIOS-Zeit als UTC(GreenwichMeantime) zu interpretieren.
Bei Archlinux wird das geregelt durch die HARDWARECLOCK-variable in der rc.conf und die TIMEZONE(DE = Europe/Berlin)
Die BIOS-Uhr nach der jeweiligen Lokalzeit gestellt zu haben macht eigentlich die größten Probleme. Sowohl beim Auslesen als auch beim Stellen:
(NB: für die Veränderung der BIOS-Zeit unterscheide ich zwischen Stellen(also kleine Korrekturen im Sek/Min-Bereich) und Verstellen(große Änderungen durch z.B. Sommer/Winterzeit oder Wechsel von Zeitzonen). Generell ist das Verstellen eigentlich nicht nötig und gewollt (also immer auf Lokalzeit), da es das System wieder (s.o.) zu Interpretationen zwingt.
Lokalzeit (und somit das immer wiederkehrende Verstellen der BIOS-Uhr) ist anhand zwei Beispielen so blöd:
a) Ich habe meine Uhr am Laptop im BIOS auf Lokalzeit (aktuell eben CET), die Uhrzeit stimmt (date zeigt die richtige Zeit und Zeitzone an). Jetzt hocke ich mich ins Flugzeug nach London, boote dort meinen Laptop - ha! falsche Zeit. Klar, ich muß die Zeitzone auf Europe/London stellen. Das passiert erstmal im System(Software). Die BIOS-Uhr hat aber immer noch eine "falsche" Zeit. Beim Runterfahren mit Lokalzeit als Option wird/muß nun die BIOS-Uhr *verstellt* werden auf Londoner Zeit. Irgendwann (beim Rückflug oder beim Weiterflug in eine andere Zeitzone) wird nun das Einfache Umstellen der Zeitzone nicht mehr ausreichen, da die einzige "Referenzuhr" im BIOS "falsch" gehen wird - und sich auch durch die Differenzangaben in den jeweiligen Zeitzonen-Dateien nicht mehr korrigieren lassen wird.
b) Alleine zwei Betriebssysteme auf einem PC machen schon kolossalen Ärger, da für das jeweils andere z.B. anhand der BIOS-Werte nicht ersichtlich ist ob die einetragene Lokalzeit nun z.B. schon von Sommer- auf Winterzeit umgestellt wurde. Das führt dazu, daß z.B. sowohl Windows als auch Linux per Software auf CET umstellen - dabei aber jeweils diese Zeit auch als Lokalzeit im BIOS eintragen - einmal ist dann zuviel ;-)
Abhilfe (und um das ständige *Verstellen* der BIOS-Uhr zu vermeiden) schafft hier die BIOS-Uhr fix nach UTC/GreenwichMeantime gestellt zu haben. Alle Zeitzonen-Vorgänge nehmen UTC/GMT als Ausgangsreferenz um Zeit/Datumsdifferenzen hinzu/abzuziehen. Also bietet sich es an, diese Zeit auch im BIOS zu Verwenden. Vorteile: das System muß die Initial/BIOS-Zeit nicht mehr versuchen zu interpretieren (das Laptop-Beispiel: das BIOS hat immer die korrekte UTC-Zeit, egal ob ich in Berlin, Lissabon oder Tokio bin - ich muß lediglich die richtige Zeitzone einstellen. Trotz des Hopings muß die BIOS-Uhr lediglich *gestellt* werden, aber nicht mehr *verstellt*).
Auch Windows und Linux müßten sich nicht mehr "bekriegen" (ist nicht auf Windows beschränkt, selbst Archlinux und Ubuntu auf dem PC machen sich die "zeit kaputt" wenn beide von CEST auf CET umstellen und das unbedingt noch bis ins BIOS austragen müssen -> Loakzeit).
Der Nachteil bei Windows ist, daß es nicht einfach ist, dieses auf eine UTC-basierende Uhrzeit zu stellen. Zumindest bis XP bedarf es händischer Eingriffe in die Registry. Dann "tastet" Windows die BIOS-Uhr auch nicht mehr an bzw. schreibt die Uhrzeit auch als UTC ins BIOS. Von einem Bekannten weiß ich allerdings, daß nach einem Suspend regelmäßg (wieder) die falsche Uhrzeit *im System* angezeigt wird, dort fehlt wohl noch irgendwas in der Registry.
Mein Tip für Linux/Windows (evtl. hat jemand eine wasserdichte Seite/Link für UTC unter Windows?) ist: Vergiß Windows, stelle v.a. a das Windows ebenfalls Sommer/Winterzeit umstellt, lebe ggf. mit einer falschen Uhrzeit in Windows. Geht natürlich nur, wenn Windows nur zum "Spielen" oder sonstwas verwendet wird...
Stellt eure Bios-Uhr auf UTC, teilt das Archlinux in der rc.conf->HARDWARECLOCK mit und gut ist.
NTP: Bist du dir sicher, überhaupt einen ntp*D* zu brauchen? Ein ntpd macht eigentlich nur Sinn wenn ich a) anderen Rechnern im Netz die Uhrzeit bereitstellen will und b) bei Servern/Rechnern, die bis auf die Millisekunde genaue Uhrzeit brauchen (z.B. für Datenbank-Transaktionen) *und* die untereinander synchron laufen müssen (da z.B. Datenbanken verteilt sind). Für diese ist es wichtig, daß die Uhrzeit immer aktuell ist und (das macht der ntpd) über Tage/Monate/Jahre minimal korrigiert werden.
Durch einen NTP(d) einen falsch konfigurierten Rechner bzgl. Hardware-Uhr und Zeitzonen quasi per Holzhammer beherrschen zu wollen, daß halte ich für schlechten Stil ("Nimm doch ntpdate" - kommt regelmäßig als "Tip" nach einer Zeitumstellung).
Mein Tip:
Stelle die rc.conf auf HARDWARECLOCK="UTC" um, Zeitzone sollte ja sowieso "Europe/Berlin" sein wenn in DE.
Beim nächsten Boot gehe ins BIOS und stelle die Uhr nach UTC (aktuell bei CET/Winterzeit 1 Stunde vor der Lokalzeit). Du wirst unter Linux(en) nie mehr Probleme mit der Zeit haben, selbst wenn du am Tag der Zeitumstellung erst ein Archlinux dann ein Debian bootest - vorrausgesetzt beide "wissen" das die Hardware-Uhr im BIOS die Zeit als UTC hat.
Für Windows suche dir Anleitungen "windows uhr utc" damit Windows zumindest die UTC-Bios-Uhr für das Linux nicht "kaputtmacht" (sind ein paar registry-Keys), stelle die Umstellung Winter/Sommerzeit ab und auch den ntp/Zeitserver-Funktion (geht über die Uhr->Einstellungen). Lebe in Windows mit oftmals falschen Uhrzeiten.
Wenn das keine Option ist, dann ist meine Erfahrung:
Nimm bei Linux und Windows jeweils den Dinest eines zeitservers in Anspruch (Windows eh aktiv per Default, bei Linux eben z.B. ntpd -g in der rc.local). bei beiden Systemen mußt du halt zeitweise mit "Zeitsprüngen" rechnen (v.a. in den Logfiles). Ist zwar IMHO absolut unsauber, aber für einen Desktop-Rechner tragbar.
Den ntpd als Dienst würde ich auf einem Desktop-PC nicht unbedingt laufen lassen (außer es ist richtig konfiguriert und es gibt kein Kuddelmuddel s.o. mit anderen Systemen). Ich würde ntpd -g in der rc.local einmal pro Boot laufen lassen oder halt per Hand aufrufen wenn die Zeit mal gröber abweichen sollte (+/- paar Minuten).
Bei weiteren Problemen (nach dem Roman <g>) wäre halt an Infos wichtig:
a) Deine Zeit im BIOS
b) deine Einstellungen bzgl. Date/Time in der rc.conf
c) Ausgabe von date in einem Terminal
d) sicherheitshalber die Angabe der lokalen Zeit im Beitrag wann du z.B. obiges date ausgeführt hast... (um 17:30 habe ich date mit folgender Ausgabe gemacht...)