mikrocontroller.net

Forum: PC Hard- und Software Wo ist definiert, wie der Lenny-Timer betrieben wird?


Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In welcher Konfigurationsdatei ist hinterlegt, ob die RTC auf UTC, oder 
Local Time läuft? Kann man das nachträglich umsetzen?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"man hwclock" => /etc/adjtime

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke!

Und wo muß man auf einem Kommandozeilensystem drehen, daß die Systemzeit 
per NTP geholt wird?

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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".

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, ntp habe ich installiert und Server in /etc/ntp.conf eingetragen. 
Mal sehen, obs funktioniert.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hm, ntpdate meint: ntpdate[2390]: no servers can be used, exiting

In /etc/ntp.conf sind zwei Server eingetragen.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christoph H. (wtzm)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Um zu überprüfen mit welchen servern der lokale ntp daemon Kontakt hält, 
kannst Du ntpq aufrufen; dort dann den Befehl peers verwenden.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
ntpq -p zählt alle 6 Server auf, nachdem ich ntp wieder gestartet hatte. 
5 davon antworten.

Autor: Andreas Ferber (aferber)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Uhu Uhuhu schrieb:
> In welcher Konfigurationsdatei ist hinterlegt, ob die RTC auf UTC, oder
> Local Time läuft? Kann man das nachträglich umsetzen?
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:
% date       
Fri Sep 24 19:24:04 CEST 2010
% TZ=EST date
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:
/etc/init.d/ntpdate start

Andreas

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es ist wie verhext: Egal, was ich anstelle, beim nächsten Boot steht die 
RTC wieder auf UTC.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Und was stört dich daran?

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :)

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Uhu Uhuhu (uhu)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!]

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.