Hallo Liste, da ich mich inzwischen seit gestern weitgehend erfolglos durch Google, Foren, und HowTo's wälze und ich noch was anderes zu tun habe :-), stelle ich hier mal mein Problem zur Diskusion: Ich habe auf meinem SUSE 10.2-System eingestellt, dass die Uhr mit der Atomuhr von der PTB abgeglichen werden soll. Anbei die ntp.conf zur Ansicht. Soweit so gut: Beim Booten allerdings erscheint folgende Meldung: Try to get initial date and time via NTP from 192.53.103.108 192.53.103.104failed Starting network time protocol daemon (NTPD)done Sprich: Der Zeitabgleich mit Braunschweig schlägt fehl; aber der Daemon startet erfolgreich. Seltsamerweise ist direkt nach dem Starten von KDE die Uhrzeit mit der Atomuhr syncron, aber wenn die Kiste ne halbe Stunde läuft, verstellt sich die Uhr automatisch vorwärts, so dass spät. nach 2 Stunden PC-Betrieb die PC-Uhr ca. 30 Minuten von der tatsächlichen Uhrzeit abweicht. Was läuft da falsch? Vielen Dank für eure Antworten im Voraus! Schöne Grüße und einen schönen Samstagabend! Christian
Am 09.06.07 schrieb Christian Pubanz <mail@christianpubanz.de>:
Ich habe auf meinem SUSE 10.2-System eingestellt, dass die Uhr mit der Atomuhr von der PTB abgeglichen werden soll. Anbei die ntp.conf zur Ansicht.
Nimm keine IP-Adressen, sondern Namen. Bspw. 0.de.pool.ntp.org und 1.de.pool.ntp.org
Was läuft da falsch?
Was sagt ntpq -p ? Gruß Martin -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Samstag, 9. Juni 2007 19:03 schrieb Martin Schröder:
Nimm keine IP-Adressen, sondern Namen. Bspw. 0.de.pool.ntp.org und 1.de.pool.ntp.org
Was sagt ntpq -p ?
Hallo Martin, wenn ich den DNS (ptbtime1.ptb.de, ptbtime2.ptb.de) statt der IP eintrage, kommt's auf's gleiche raus...:-| Die Ausgabe von ntpq -p: remote refid st t when poll reach delay offset jitter ============================================================================== ptbtime1.ptb.de .PTB. 1 u 2 1024 377 32.943 -212238 30911.4 *LOCAL(0) .LOCL. 13 l 30 64 377 0.000 0.000 0.001 ptbtime2.ptb.de .PTB. 1 u 1020 1024 377 32.903 -212419 30881.2 Gruß, Christian -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am 09.06.07 schrieb Christian Pubanz <mail@christianpubanz.de>:
wenn ich den DNS (ptbtime1.ptb.de, ptbtime2.ptb.de) statt der IP eintrage, kommt's auf's gleiche raus...:-|
Firewall? Versuch mal den ntpdate-Aufruf aus /etc/init.d/ntp zusammenzubauen und händisch abzusetzen.
Die Ausgabe von ntpq -p:
remote refid st t when poll reach delay offset jitter ============================================================================== ptbtime1.ptb.de .PTB. 1 u 2 1024 377 32.943 -212238 30911.4 *LOCAL(0) .LOCL. 13 l 30 64 377 0.000 0.000 0.001 ptbtime2.ptb.de .PTB. 1 u 1020 1024 377 32.903 -212419 30881.2
Da stört ihn vermutlich schon der doch etwas große Offset... Gruß Martin -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Christian Pubanz schrieb:
Hallo Liste,
da ich mich inzwischen seit gestern weitgehend erfolglos durch Google, Foren, und HowTo's wälze und ich noch was anderes zu tun habe :-), stelle ich hier mal mein Problem zur Diskusion:
Ich habe auf meinem SUSE 10.2-System eingestellt, dass die Uhr mit der Atomuhr von der PTB abgeglichen werden soll. Anbei die ntp.conf zur Ansicht.
Soweit so gut:
Beim Booten allerdings erscheint folgende Meldung:
Try to get initial date and time via NTP from 192.53.103.108 192.53.103.104failed Starting network time protocol daemon (NTPD)done
Sprich: Der Zeitabgleich mit Braunschweig schlägt fehl; aber der Daemon startet erfolgreich. Seltsamerweise ist direkt nach dem Starten von KDE die Uhrzeit mit der Atomuhr syncron, aber wenn die Kiste ne halbe Stunde läuft, verstellt sich die Uhr automatisch vorwärts, so dass spät. nach 2 Stunden PC-Betrieb die PC-Uhr ca. 30 Minuten von der tatsächlichen Uhrzeit abweicht.
Was läuft da falsch?
Der NTP Daemon startet standardmäßig in Runlevel 2. IMO das ist zu früh. setze ihn nur auf 3 und 5 dann müsste er laufen. In Runlevel 2 startet er vor der IP-Zuweisung der Netzwerkkarte. Sag bescheid wenn's funktioniert. Hab' gerade wenig Zeit zum testen. Danke Jan -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am 09.06.07 schrieb Jan Tiggy <mail.list@gmx.net>:
Der NTP Daemon startet standardmäßig in Runlevel 2. IMO das ist zu früh. setze ihn nur auf 3 und 5 dann müsste er laufen. In Runlevel 2 startet er vor der IP-Zuweisung der Netzwerkkarte. Sag
Hä? Er startet nach network, das muß reichen. Gruß Martin -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Martin Schröder schrieb:
Am 09.06.07 schrieb Jan Tiggy <mail.list@gmx.net>:
Der NTP Daemon startet standardmäßig in Runlevel 2. IMO das ist zu früh. setze ihn nur auf 3 und 5 dann müsste er laufen. In Runlevel 2 startet er vor der IP-Zuweisung der Netzwerkkarte. Sag
Hä? Er startet nach network, das muß reichen.
Bei mir tut er es nicht. Bei mir startet er vor dem Netzwerk, und das kann nicht hinhauen. Bei mir kommt erst der NTP und erst dann das Netzwerk. Ich weiß, es ist seltsam. Aber es ist leider so. Nachdem ich den NTP auf 3,5 gesetzt habe, läuft alles. Leider bin ich zur Zeit überfragt. Sorry. Thx Jan -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Samstag, 9. Juni 2007 18:56 schrieb Christian Pubanz:
Hallo Liste,
da ich mich inzwischen seit gestern weitgehend erfolglos durch Google, Foren, und HowTo's wälze und ich noch was anderes zu tun habe :-), stelle ich hier mal mein Problem zur Diskusion:
Ich habe auf meinem SUSE 10.2-System eingestellt, dass die Uhr mit der Atomuhr von der PTB abgeglichen werden soll. Anbei die ntp.conf zur Ansicht.
Soweit ich weis, sollte nicht jeder Client die PTB belasten. Nimm besser die Pool Server: <http://de.wikipedia.org/wiki/NTP_pool> oder NTP Server Deines Providers. Bei der Telekom sind das z.B. server ntp1.sda.t-online.de server ntp1.sul.t-online.de
Soweit so gut:
Beim Booten allerdings erscheint folgende Meldung:
Try to get initial date and time via NTP from 192.53.103.108 192.53.103.104failed Starting network time protocol daemon (NTPD)done
Sprich: Der Zeitabgleich mit Braunschweig schlägt fehl; aber der Daemon startet erfolgreich. Seltsamerweise ist direkt nach dem Starten von KDE die Uhrzeit mit der Atomuhr syncron,
Womit wurde denn in laut /var/log/ntp synchronisiert?
aber wenn die Kiste ne halbe Stunde läuft, verstellt sich die Uhr automatisch vorwärts, so dass spät. nach 2 Stunden PC-Betrieb die PC-Uhr ca. 30 Minuten von der tatsächlichen Uhrzeit abweicht.
Ergänze mal Deine google Suchen um das Stichwort "drift". Soweit ich weis stellt der NTP Client Abweichungen zwischen den Zeiten vom NTP Server und der RTC (Deiner Hardwareuhr) fest und speichert diese in der Datei /var/lib/ntp/drift/ntp.drift Nach der dort gespeicherten Abweichung wird die Systemzeit (das ist die "angezeigte" Zeit, nicht die RTC) korrigiert. Benenne mal diese Datei um, und schaue nach, ob die Abweichungen noch auftreten. Grüße Ralf -- Antworten bitte nur in die Mailingliste! PMs bitte an: listreply (@) arndt-on-line (.) de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Samstag, 9. Juni 2007 18:56 schrieb Christian Pubanz:
(...). Ich habe auf meinem SUSE 10.2-System eingestellt, dass die Uhr mit der Atomuhr von der PTB abgeglichen werden soll. Anbei die ntp.conf zur Ansicht. (...).
Hast du das mit YaST eingestellt? Oder nur in der ntp.conf? Ich bin mir nicht sicher, ob man im letzteren Fall nicht noch die SuSEfirewall entsprechend selbst konfigurieren muß (ich mache das immer, kA ob was noch wirklich notwendig ist).
Try to get initial date and time via NTP from 192.53.103.108 192.53.103.104failed Starting network time protocol daemon (NTPD)done
Sprich: Der Zeitabgleich mit Braunschweig schlägt fehl;
Das ist schonmal schlecht. Was sagt denn der Debug-Modus von ntpdate: ntpdate -d ntp1.ptb.de
aber der Daemon startet erfolgreich.
Starten schon, aber das heißt ja nicht, daß er tatsächlich funktioniert. Dafür mußt du in /var/log/ntp nachsehen.
(...). so dass spät. nach 2 Stunden PC-Betrieb die PC-Uhr ca. 30 Minuten von der tatsächlichen Uhrzeit abweicht.
Was läuft da falsch? (...).
So eine Abweichung ist an sich schon sehr merkwürdig bzw. falsch. Probier mal die Vorgehensweise aus http://de.opensuse.org/SDB:Rechner-Uhr_geht_zu_schnell_oder_zu_langsam -- I can understand that the Universe is unfair, but why isn't ever unfair in my favor? -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Samstag, 9. Juni 2007 schrieb Christian Pubanz:
Hallo Liste,
da ich mich inzwischen seit gestern weitgehend erfolglos durch Google, Foren, und HowTo's wälze und ich noch was anderes zu tun habe :-), stelle ich hier mal mein Problem zur Diskusion:
Ich habe auf meinem SUSE 10.2-System eingestellt, dass die Uhr mit der Atomuhr von der PTB abgeglichen werden soll. Anbei die ntp.conf zur Ansicht.
Soweit so gut:
Beim Booten allerdings erscheint folgende Meldung:
Try to get initial date and time via NTP from 192.53.103.108 192.53.103.104failed Starting network time protocol daemon (NTPD)done
Sprich: Der Zeitabgleich mit Braunschweig schlägt fehl; aber der Daemon startet erfolgreich. Seltsamerweise ist direkt nach dem Starten von KDE die Uhrzeit mit der Atomuhr syncron, aber wenn die Kiste ne halbe Stunde läuft, verstellt sich die Uhr automatisch vorwärts, so dass spät. nach 2 Stunden PC-Betrieb die PC-Uhr ca. 30 Minuten von der tatsächlichen Uhrzeit abweicht.
Was läuft da falsch?
Vielen Dank für eure Antworten im Voraus!
Schöne Grüße und einen schönen Samstagabend!
Christian
Hallo Christian Ich hab das selbe Problem hier wenn ich den parallel Boot verwende. Irgendwie scheinen sich da die init Scripte zu überholen, anders kann ich mir das nicht erklären. Wenn ich jedoch mit Yast in den Systemeinstellunen mit dem "Editor für Sysconfig Dateien" unter System/Boot/RUN_PARALLEL den Wert auf No setze, werden die Scripte nacheinander sauber abgearbeitet, und die Fehlermeldung tritt nicht mehr auf. Vielleicht hilfts ja auch bei Dir Micha -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Sonntag, 10. Juni 2007 19:09 schrieb Michael Schueller:
Ich hab das selbe Problem hier wenn ich den parallel Boot verwende. Irgendwie scheinen sich da die init Scripte zu überholen, anders kann ich mir das nicht erklären.
Wenn ich jedoch mit Yast in den Systemeinstellunen mit dem "Editor für Sysconfig Dateien" unter System/Boot/RUN_PARALLEL den Wert auf No setze, werden die Scripte nacheinander sauber abgearbeitet, und die Fehlermeldung tritt nicht mehr auf.
Vielleicht hilfts ja auch bei Dir
Hallo Micha und die anderen! Vielen Dank für eure Zuschriften! Ich kann das Problem dank eurer Hinweise nun genauer eingrenzen: Es liegt wohl daran, dass der NTPD nicht richtig läuft. Anbei die /var/boot/ntp. Ich kann mir nicht erklären, wehalb er sich immer beendet. Firewall hab ich übrigens aus-und die Ausgabe von ntp- d ergibt: 10 Jun 23:23:49 ntpdate[4308]: ntpdate 4.2.2p4@1.1585-o Sat Nov 25 18:44:36 UTC 2006 (1) Looking for host ntp1.ptb.de and service ntp host found : ptbtime1.ptb.de transmit(192.53.103.108) receive(192.53.103.108) transmit(192.53.103.108) receive(192.53.103.108) transmit(192.53.103.108) receive(192.53.103.108) transmit(192.53.103.108) receive(192.53.103.108) transmit(192.53.103.108) server 192.53.103.108, port 123 stratum 1, precision -23, leap 00, trust 000 refid [PTB], delay 0.05864, dispersion 0.00107 transmitted 4, in filter 4 reference time: ca16e9d1.7a94d66b Sun, Jun 10 2007 23:21:21.478 originate timestamp: ca16ea03.6a606f89 Sun, Jun 10 2007 23:22:11.415 transmit timestamp: ca16ea65.d4209246 Sun, Jun 10 2007 23:23:49.828 filter delay: 0.05875 0.05870 0.05864 0.05875 0.00000 0.00000 0.00000 0.00000 filter offset: -98.4263 -98.4274 -98.4283 -98.4296 0.000000 0.000000 0.000000 0.000000 delay 0.05864, dispersion 0.00107 offset -98.428332 10 Jun 23:23:49 ntpdate[4308]: step time server 192.53.103.108 offset -98.428332 sec Eingestellt hab ich die Server via Yast. Aber wie gesagt, ich vermute den NTPD dahinter. Kann ich den "zwingen" sich nicht zu beenden? Grüße Christian
Hallo, On 6/10/2007 11:27 PM, Christian Pubanz wrote: ...
Hallo Micha und die anderen!
Vielen Dank für eure Zuschriften!
Ich kann das Problem dank eurer Hinweise nun genauer eingrenzen:
Es liegt wohl daran, dass der NTPD nicht richtig läuft. Anbei die /var/boot/ntp. Ich kann mir nicht erklären, wehalb er sich immer beendet.
Firewall hab ich übrigens aus-und die Ausgabe von ntp- d ergibt:
10 Jun 23:23:49 ntpdate[4308]: ntpdate 4.2.2p4@1.1585-o Sat Nov 25 18:44:36 UTC 2006 (1) Looking for host ntp1.ptb.de and service ntp host found : ptbtime1.ptb.de ... 10 Jun 23:23:49 ntpdate[4308]: step time server 192.53.103.108 offset -98.428332 sec
Das läuft richtig.
Eingestellt hab ich die Server via Yast. Aber wie gesagt, ich vermute den NTPD dahinter. Kann ich den "zwingen" sich nicht zu beenden?
Dein ntp.log scheint zu sagen dass ntp das letzte Mal am 17. März beendet wurde. Also vermute ich mal dass der gar nicht gestartet wird, oder läuft der Rechner so lange durch? In /etc/sysconfig/ntp sollte eine Zeile NTPD_START="yes" stehen. Tut es das nicht, dann ergänze die mal und starte das ntp-Zeug mit '/etc/rc.d/ntp start' nochmal. Dann schau' nochmal in die ntp.log Datei. Steht das schon drin, und ntp läuft nicht, dann starte ntp mal von Hand mit 'ntpd -D 1 -p /var/lib/ntp/var/run/ntp/ntpd.pid -u ntp'. Das sollte zumindest eine Menge Aktivität im Terminal erzeugen. Wenn das dann abbricht solltest du eine Fehlermeldung sehen können. Mit Strg-C kannst du den Prozess dann abbrechen, falls es keinen Programmabbruch gibt. In letzterem Fall würde ich annehmen dass ein Konfigurationsproblem vorliegt. Poste dann mal den Inhalt von /etc/sysconfig/ntp - vielleicht fällt daran was auf. Arno
Grüße Christian
------------------------------------------------------------------------
15 Mar 19:59:02 ntpd[5977]: ntpd exiting on signal 15 15 Mar 20:01:00 ntpd[2990]: ntpd exiting on signal 15 15 Mar 20:04:12 ntpd[3266]: synchronized to LOCAL(0), stratum 10 15 Mar 20:04:12 ntpd[3266]: kernel time sync enabled 0001 15 Mar 22:03:30 ntpd[3266]: ntpd exiting on signal 15 16 Mar 09:20:49 ntpd[3094]: ntpd exiting on signal 15 16 Mar 09:24:00 ntpd[3476]: synchronized to LOCAL(0), stratum 10 16 Mar 09:24:00 ntpd[3476]: kernel time sync enabled 0001 16 Mar 10:02:58 ntpd[3476]: ntpd exiting on signal 15 16 Mar 10:42:58 ntpd[2985]: ntpd exiting on signal 15 16 Mar 10:46:16 ntpd[3479]: synchronized to LOCAL(0), stratum 10 16 Mar 10:46:16 ntpd[3479]: kernel time sync enabled 0001 16 Mar 11:00:38 ntpd[3479]: ntpd exiting on signal 15 16 Mar 10:45:56 ntpd[4079]: ntpd exiting on signal 15 16 Mar 10:49:09 ntpd[4154]: synchronized to LOCAL(0), stratum 10 16 Mar 10:49:09 ntpd[4154]: kernel time sync enabled 0001 16 Mar 11:24:55 ntpd[4154]: ntpd exiting on signal 15 16 Mar 11:25:55 ntpd[4610]: ntpd exiting on signal 15 16 Mar 11:23:16 ntpd[4719]: ntpd exiting on signal 15 16 Mar 11:26:31 ntpd[4767]: synchronized to LOCAL(0), stratum 10 16 Mar 11:26:31 ntpd[4767]: kernel time sync enabled 0001 16 Mar 13:16:04 ntpd[4767]: ntpd exiting on signal 15 16 Mar 13:08:59 ntpd[5382]: ntpd exiting on signal 15 16 Mar 13:10:07 ntpd[5428]: ntpd exiting on signal 15 16 Mar 14:03:47 ntpd[3070]: ntpd exiting on signal 15 16 Mar 16:09:10 ntpd[3045]: ntpd exiting on signal 15 16 Mar 16:15:12 ntpd[4189]: synchronized to LOCAL(0), stratum 10 16 Mar 16:15:12 ntpd[4189]: kernel time sync enabled 0001 16 Mar 22:59:25 ntpd[4189]: ntpd exiting on signal 15 17 Mar 10:24:01 ntpd[2996]: ntpd exiting on signal 15 17 Mar 12:30:07 ntpd[3031]: ntpd exiting on signal 15 17 Mar 11:54:29 ntpd[3100]: synchronized to LOCAL(0), stratum 10 17 Mar 11:54:29 ntpd[3100]: kernel time sync enabled 0001 17 Mar 13:03:33 ntpd[3100]: ntpd exiting on signal 15 17 Mar 13:34:26 ntpd[2904]: ntpd exiting on signal 15 17 Mar 15:41:04 ntpd[2968]: ntpd exiting on signal 15 17 Mar 16:12:42 ntpd[4157]: synchronized to LOCAL(0), stratum 10 17 Mar 16:12:42 ntpd[4157]: kernel time sync enabled 0001 17 Mar 16:19:43 ntpd[4157]: ntpd exiting on signal 15 17 Mar 16:21:40 ntpd[2916]: ntpd exiting on signal 15 17 Mar 16:32:31 ntpd[2983]: ntpd exiting on signal 15
-- IT-Service Lehmann al@its-lehmann.de Arno Lehmann http://www.its-lehmann.de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Sonntag, 10. Juni 2007 23:55 schrieb Arno Lehmann:
Also vermute ich mal dass der gar nicht gestartet wird, oder läuft der Rechner so lange durch?
In /etc/sysconfig/ntp sollte eine Zeile NTPD_START="yes" stehen.
Tut es das nicht, dann ergänze die mal und starte das ntp-Zeug mit '/etc/rc.d/ntp start' nochmal. Dann schau' nochmal in die ntp.log Datei.
Steht das schon drin, und ntp läuft nicht, dann starte ntp mal von Hand mit 'ntpd -D 1 -p /var/lib/ntp/var/run/ntp/ntpd.pid -u ntp'. Das sollte zumindest eine Menge Aktivität im Terminal erzeugen. Wenn das dann abbricht solltest du eine Fehlermeldung sehen können.
Mit Strg-C kannst du den Prozess dann abbrechen, falls es keinen Programmabbruch gibt. In letzterem Fall würde ich annehmen dass ein Konfigurationsproblem vorliegt. Poste dann mal den Inhalt von /etc/sysconfig/ntp - vielleicht fällt daran was auf.
Hi Arno, ich hab jetzt mal deinen genannten Befehl ausgeführt in der Hoffnung, du kannst das Ergebnis für mich übersetzen, denn ich versehe davon eigentlich nichts! noname:/home/christian # ntpd -D 1 -p /var/lib/ntp/var/run/ntp/ntpd.pid -u ntp Debug1: 1 -> 1 = 1 ntpd 4.2.2p4@1.1585-o Sat Nov 25 18:44:34 UTC 2006 (1) Debug1: 1 -> 1 = 1 addto_syslog: precision = 1.000 usec create_sockets(123) addto_syslog: ntp_io: estimated max descriptors: 1024, initial socket boundary: 16 addto_syslog: bind() fd 16, family 2, port 123, addr 0.0.0.0, in_classd=0 flags= 9 fails: Address already in use addto_syslog: bind() fd 16, family 10, port 123, scope 0, addr ::, in6_is_addr_m ulticast=0 flags=1 fails: Address already in use addto_syslog: bind() fd 16, family 10, port 123, scope 0, addr ::1, in6_is_addr_ multicast=0 flags=1 fails: Address already in use addto_syslog: bind() fd 16, family 10, port 123, scope 2, addr fe80::230:5ff:fe2 1:53e6, in6_is_addr_multicast=0 flags=1 fails: Address already in use addto_syslog: bind() fd 16, family 2, port 123, addr 127.0.0.1, in_classd=0 flag s=5 fails: Address already in use addto_syslog: bind() fd 16, family 2, port 123, addr 192.168.178.21, in_classd=0 flags=25 fails: Address already in use init_io: maxactivefd 0 local_clock: time 0 base 0.000000 offset 0.000000 freq 0.000 state 0 Debug2: 1 -> 1 = 1 key_expire: at 0 peer_clear: at 0 next 1 assoc ID 32319 refid INIT newpeer: 192.168.178.21->192.53.103.108 mode 3 vers 4 poll 6 10 flags 0x1 0x1 tt l 0 key 00000000 key_expire: at 0 peer_clear: at 0 next 2 assoc ID 32320 refid INIT newpeer: 127.0.0.1->127.127.1.0 mode 3 vers 4 poll 6 10 flags 0x1021 0x1 ttl 0 k ey 00000000 key_expire: at 0 peer_clear: at 0 next 3 assoc ID 32321 refid INIT newpeer: 192.168.178.21->192.53.103.104 mode 3 vers 4 poll 6 10 flags 0x1 0x1 tt l 0 key 00000000 report_event: system event 'event_restart' (0x01) status 'sync_alarm, sync_unspe c, 1 event, event_unspec' (0xc010) addto_syslog: sendto(192.53.103.108) (fd=-1): Bad file descriptor transmit: at 1 192.168.178.21->192.53.103.108 mode 3 auth_agekeys: at 1 keys 1 expired 0 timer: refresh ts 0 refclock_transmit: at 2 127.127.1.0 refclock_receive: at 2 127.127.1.0 peer LOCAL(0) event 'event_reach' (0x84) status 'unreach, conf, 1 event, event_r each' (0x8014) refclock_sample: n 1 offset 0.000000 disp 0.010000 jitter 0.000001 clock_filter: n 1 off 0.000000 del 0.000000 dsp 7.937500 jit 0.000001, age 0 filegen 2 3390580938 0 3390508800 addto_syslog: sendto(192.53.103.104) (fd=-1): Bad file descriptor transmit: at 3 192.168.178.21->192.53.103.104 mode 3 auth_agekeys: at 60 keys 1 expired 0 refclock_transmit: at 66 127.127.1.0 refclock_receive: at 66 127.127.1.0 refclock_sample: n 1 offset 0.000000 disp 0.010000 jitter 0.000001 clock_filter: n 2 off 0.000000 del 0.000000 dsp 3.937741 jit 0.000001, age 0 filegen 2 3390581002 0 3390508800 addto_syslog: sendto(192.53.103.108) (fd=-1): Bad file descriptor transmit: at 66 192.168.178.21->192.53.103.108 mode 3 addto_syslog: sendto(192.53.103.104) (fd=-1): Bad file descriptor transmit: at 67 192.168.178.21->192.53.103.104 mode 3 auth_agekeys: at 120 keys 1 expired 0 addto_syslog: sendto(192.53.103.108) (fd=-1): Bad file descriptor transmit: at 130 192.168.178.21->192.53.103.108 mode 3 refclock_transmit: at 132 127.127.1.0 refclock_receive: at 132 127.127.1.0 refclock_sample: n 1 offset 0.000000 disp 0.010000 jitter 0.000001 clock_filter: n 3 off 0.000000 del 0.000000 dsp 1.937992 jit 0.000001, age 0 filegen 2 3390581068 0 3390508800 addto_syslog: sendto(192.53.103.104) (fd=-1): Bad file descriptor transmit: at 132 192.168.178.21->192.53.103.104 mode 3 auth_agekeys: at 180 keys 1 expired 0 addto_syslog: sendto(192.53.103.104) (fd=-1): Bad file descriptor transmit: at 195 192.168.178.21->192.53.103.104 mode 3 addto_syslog: sendto(192.53.103.108) (fd=-1): Bad file descriptor transmit: at 196 192.168.178.21->192.53.103.108 mode 3 refclock_transmit: at 197 127.127.1.0 refclock_receive: at 197 127.127.1.0 refclock_sample: n 1 offset 0.000000 disp 0.010000 jitter 0.000001 clock_filter: n 4 off 0.000000 del 0.000000 dsp 0.938173 jit 0.000001, age 0 report_event: system event 'event_peer/strat_chg' (0x04) status 'sync_alarm, sync_local_proto, 2 events, event_restart' (0xc521) addto_syslog: synchronized to LOCAL(0), stratum 13 clock_update: at 197 assoc 3 local_clock: assocID 32320 offset 0.000000000 freq 0.000 state 0 local_clock: time 197 base 0.000000 offset 0.000000 freq 0.000 state 3 filegen 2 3390581133 0 3390508800 auth_agekeys: at 240 keys 1 expired 0 addto_syslog: sendto(192.53.103.108) (fd=-1): Bad file descriptor transmit: at 260 192.168.178.21->192.53.103.108 mode 3 refclock_transmit: at 261 127.127.1.0 refclock_receive: at 261 127.127.1.0 refclock_sample: n 1 offset 0.000000 disp 0.010000 jitter 0.000001 clock_filter: n 5 off 0.000000 del 0.000000 dsp 0.438287 jit 0.000001, age 0 clock_update: at 261 assoc 3 local_clock: assocID 32320 offset 0.000000000 freq 0.000 state 3 filegen 2 3390581197 0 3390508800 addto_syslog: sendto(192.53.103.104) (fd=-1): Bad file descriptor transmit: at 261 192.168.178.21->192.53.103.104 mode 3 auth_agekeys: at 300 keys 1 expired 0 addto_syslog: sendto(192.53.103.104) (fd=-1): Bad file descriptor transmit: at 325 192.168.178.21->192.53.103.104 mode 3 refclock_transmit: at 326 127.127.1.0 refclock_receive: at 326 127.127.1.0 refclock_sample: n 1 offset 0.000000 disp 0.010000 jitter 0.000001 clock_filter: n 6 off 0.000000 del 0.000000 dsp 0.188366 jit 0.000001, age 0 clock_update: at 326 assoc 3 local_clock: assocID 32320 offset 0.000000000 freq 0.000 state 3 filegen 2 3390581262 0 3390508800 addto_syslog: sendto(192.53.103.108) (fd=-1): Bad file descriptor transmit: at 326 192.168.178.21->192.53.103.108 mode 3 auth_agekeys: at 360 keys 1 expired 0 addto_syslog: sendto(192.53.103.104) (fd=-1): Bad file descriptor transmit: at 388 192.168.178.21->192.53.103.104 mode 3 refclock_transmit: at 390 127.127.1.0 refclock_receive: at 390 127.127.1.0 refclock_sample: n 1 offset 0.000000 disp 0.010000 jitter 0.000001 clock_filter: n 7 off 0.000000 del 0.000000 dsp 0.063406 jit 0.000001, age 0 clock_update: at 390 assoc 3 local_clock: assocID 32320 offset 0.000000000 freq 0.000 state 3 filegen 2 3390581326 0 3390508800 addto_syslog: sendto(192.53.103.108) (fd=-1): Bad file descriptor transmit: at 390 192.168.178.21->192.53.103.108 mode 3 auth_agekeys: at 420 keys 1 expired 0 addto_syslog: sendto(192.53.103.104) (fd=-1): Bad file descriptor transmit: at 451 192.168.178.21->192.53.103.104 mode 3 refclock_transmit: at 455 127.127.1.0 refclock_receive: at 455 127.127.1.0 refclock_sample: n 1 offset 0.000000 disp 0.010000 jitter 0.000001 clock_filter: n 8 off 0.000000 del 0.000000 dsp 0.000937 jit 0.000001, age 0 clock_update: at 455 assoc 3 local_clock: assocID 32320 offset 0.000000000 freq 0.000 state 3 filegen 2 3390581391 0 3390508800 addto_syslog: sendto(192.53.103.108) (fd=-1): Bad file descriptor transmit: at 456 192.168.178.21->192.53.103.108 mode 3 auth_agekeys: at 480 keys 1 expired 0 addto_syslog: sendto(192.53.103.104) (fd=-1): Bad file descriptor transmit: at 515 192.168.178.21->192.53.103.104 mode 3 addto_syslog: sendto(192.53.103.108) (fd=-1): Bad file descriptor transmit: at 520 192.168.178.21->192.53.103.108 mode 3 refclock_transmit: at 521 127.127.1.0 refclock_receive: at 521 127.127.1.0 refclock_sample: n 1 offset 0.000000 disp 0.010000 jitter 0.000001 clock_filter: n 8 off 0.000000 del 0.000000 dsp 0.000947 jit 0.000001, age 0 clock_update: at 521 assoc 3 local_clock: assocID 32320 offset 0.000000000 freq 0.000 state 3 filegen 2 3390581457 0 3390508800 auth_agekeys: at 540 keys 1 expired 0 addto_syslog: sendto(192.53.103.104) (fd=-1): Bad file descriptor transmit: at 581 192.168.178.21->192.53.103.104 mode 3 refclock_transmit: at 584 127.127.1.0 refclock_receive: at 584 127.127.1.0 refclock_sample: n 1 offset 0.000000 disp 0.010000 jitter 0.000001 clock_filter: n 8 off 0.000000 del 0.000000 dsp 0.000929 jit 0.000001, age 0 clock_update: at 584 assoc 3 local_clock: assocID 32320 offset 0.000000000 freq 0.000 state 3 filegen 2 3390581520 0 3390508800 addto_syslog: sendto(192.53.103.108) (fd=-1): Bad file descriptor transmit: at 584 192.168.178.21->192.53.103.108 mode 3 auth_agekeys: at 600 keys 1 expired 0 addto_syslog: sendto(192.53.103.104) (fd=-1): Bad file descriptor transmit: at 646 192.168.178.21->192.53.103.104 mode 3 refclock_transmit: at 647 127.127.1.0 refclock_receive: at 647 127.127.1.0 refclock_sample: n 1 offset 0.000000 disp 0.010000 jitter 0.000001 clock_filter: n 8 off 0.000000 del 0.000000 dsp 0.000921 jit 0.000001, age 0 clock_update: at 647 assoc 3 local_clock: assocID 32320 offset 0.000000000 freq 0.000 state 3 filegen 2 3390581583 0 3390508800 addto_syslog: sendto(192.53.103.108) (fd=-1): Bad file descriptor transmit: at 648 192.168.178.21->192.53.103.108 mode 3 auth_agekeys: at 660 keys 1 expired 0 addto_syslog: sendto(192.53.103.104) (fd=-1): Bad file descriptor transmit: at 709 192.168.178.21->192.53.103.104 mode 3 refclock_transmit: at 711 127.127.1.0 refclock_receive: at 711 127.127.1.0 refclock_sample: n 1 offset 0.000000 disp 0.010000 jitter 0.000001 clock_filter: n 8 off 0.000000 del 0.000000 dsp 0.000924 jit 0.000001, age 0 clock_update: at 711 assoc 3 local_clock: assocID 32320 offset 0.000000000 freq 0.000 state 3 filegen 2 3390581647 0 3390508800 addto_syslog: sendto(192.53.103.108) (fd=-1): Bad file descriptor transmit: at 714 192.168.178.21->192.53.103.108 mode 3 auth_agekeys: at 720 keys 1 expired 0 addto_syslog: sendto(192.53.103.104) (fd=-1): Bad file descriptor transmit: at 773 192.168.178.21->192.53.103.104 mode 3 refclock_transmit: at 775 127.127.1.0 refclock_receive: at 775 127.127.1.0 refclock_sample: n 1 offset 0.000000 disp 0.010000 jitter 0.000001 clock_filter: n 8 off 0.000000 del 0.000000 dsp 0.000926 jit 0.000001, age 0 clock_update: at 775 assoc 3 local_clock: assocID 32320 offset 0.000000000 freq 0.000 state 3 filegen 2 3390581711 0 3390508800 addto_syslog: sendto(192.53.103.108) (fd=-1): Bad file descriptor transmit: at 780 192.168.178.21->192.53.103.108 mode 3 auth_agekeys: at 780 keys 1 expired 0 addto_syslog: sendto(192.53.103.104) (fd=-1): Bad file descriptor transmit: at 838 192.168.178.21->192.53.103.104 mode 3 refclock_transmit: at 840 127.127.1.0 refclock_receive: at 840 127.127.1.0 refclock_sample: n 1 offset 0.000000 disp 0.010000 jitter 0.000001 clock_filter: n 8 off 0.000000 del 0.000000 dsp 0.000934 jit 0.000001, age 0 clock_update: at 840 assoc 3 local_clock: assocID 32320 offset 0.000000000 freq 0.000 state 3 filegen 2 3390581776 0 3390508800 auth_agekeys: at 840 keys 1 expired 0 addto_syslog: sendto(192.53.103.108) (fd=-1): Bad file descriptor transmit: at 846 192.168.178.21->192.53.103.108 mode 3 auth_agekeys: at 900 keys 1 expired 0 addto_syslog: sendto(192.53.103.104) (fd=-1): Bad file descriptor transmit: at 903 192.168.178.21->192.53.103.104 mode 3 refclock_transmit: at 906 127.127.1.0 refclock_receive: at 906 127.127.1.0 refclock_sample: n 1 offset 0.000000 disp 0.010000 jitter 0.000001 clock_filter: n 8 off 0.000000 del 0.000000 dsp 0.000945 jit 0.000001, age 0 clock_update: at 906 assoc 3 local_clock: assocID 32320 offset 0.000000000 freq 0.000 state 3 filegen 2 3390581842 0 3390508800 addto_syslog: sendto(192.53.103.108) (fd=-1): Bad file descriptor transmit: at 910 192.168.178.21->192.53.103.108 mode 3 auth_agekeys: at 960 keys 1 expired 0 addto_syslog: sendto(192.53.103.104) (fd=-1): Bad file descriptor transmit: at 966 192.168.178.21->192.53.103.104 mode 3 refclock_transmit: at 971 127.127.1.0 refclock_receive: at 971 127.127.1.0 refclock_sample: n 1 offset 0.000000 disp 0.010000 jitter 0.000001 clock_filter: n 8 off 0.000000 del 0.000000 dsp 0.000944 jit 0.000001, age 0 clock_update: at 971 assoc 3 local_clock: assocID 32320 offset 0.000000000 freq 0.000 state 3 filegen 2 3390581907 0 3390508800 addto_syslog: sendto(192.53.103.108) (fd=-1): Bad file descriptor transmit: at 973 192.168.178.21->192.53.103.108 mode 3 addto_syslog: ntpd exiting on signal 2 addto_syslog: can't open /var/lib/ntp/ntp.drift.TEMP: Permission denied Weil der Prozess anscheinend ab einem gewissen Zeitpunkt stagnierte, habe ich ihn mit STRG-C beendet. Die Zeile NTPD_START="yes" stand in der /etc/sysconf/ntp natürlich bereits drin-sonst hätte ich ja den anderen Test nicht gemacht :-D Ich weiß nicht, warum der ntpd sich das letzte Mal am 17. März beendet haben soll-jedenfalls lief mein rechner bis dahin nicht durch... Ich bin-wie gesagt-völlig ratlos und hoffe da auch Tips als "Pinguin-Beschwörer" *grins* Viele Grüße Christian PS: Inhalt von /etc/sysconf/ntp anbei...
Hi, On 6/11/2007 10:42 PM, Christian Pubanz wrote:
Am Sonntag, 10. Juni 2007 23:55 schrieb Arno Lehmann:
Also vermute ich mal dass der gar nicht gestartet wird, oder läuft der Rechner so lange durch?
In /etc/sysconfig/ntp sollte eine Zeile NTPD_START="yes" stehen.
Tut es das nicht, dann ergänze die mal und starte das ntp-Zeug mit '/etc/rc.d/ntp start' nochmal. Dann schau' nochmal in die ntp.log Datei.
Steht das schon drin, und ntp läuft nicht, dann starte ntp mal von Hand mit 'ntpd -D 1 -p /var/lib/ntp/var/run/ntp/ntpd.pid -u ntp'. Das sollte zumindest eine Menge Aktivität im Terminal erzeugen. Wenn das dann abbricht solltest du eine Fehlermeldung sehen können.
Mit Strg-C kannst du den Prozess dann abbrechen, falls es keinen Programmabbruch gibt. In letzterem Fall würde ich annehmen dass ein Konfigurationsproblem vorliegt. Poste dann mal den Inhalt von /etc/sysconfig/ntp - vielleicht fällt daran was auf.
Hi Arno,
ich hab jetzt mal deinen genannten Befehl ausgeführt in der Hoffnung, du kannst das Ergebnis für mich übersetzen, denn ich versehe davon eigentlich nichts!
noname:/home/christian # ntpd -D 1 -p /var/lib/ntp/var/run/ntp/ntpd.pid -u ntp ... addto_syslog: synchronized to LOCAL(0), stratum 13
Bis hierhin nichts unerwartetes, einiges geht nicht, aber das ist für diesen Versuch nicht schlimm. Jetzt ist ntpd mit der okalen Hardware-Uhr syncronisiert. ...
addto_syslog: ntpd exiting on signal 2 Strg-C addto_syslog: can't open /var/lib/ntp/ntp.drift.TEMP: Permission denied
Weil der Prozess anscheinend ab einem gewissen Zeitpunkt stagnierte, habe ich ihn mit STRG-C beendet.
Ja, sehe ich :-)
Die Zeile NTPD_START="yes" stand in der /etc/sysconf/ntp natürlich bereits drin-sonst hätte ich ja den anderen Test nicht gemacht :-D
Gut.
Ich weiß nicht, warum der ntpd sich das letzte Mal am 17. März beendet haben soll-jedenfalls lief mein rechner bis dahin nicht durch...
Ich bin-wie gesagt-völlig ratlos und hoffe da auch Tips als "Pinguin-Beschwörer" *grins*
Tja, ich kann keine Pinguine beschwören, aber ich guck' die gerne an :-) Wie auch immer, das obige sieht aus als sollte ntpd laufen können - zumindest geht die Test-Session korrekt.
Viele Grüße
Christian
PS: Inhalt von /etc/sysconf/ntp anbei...
Sieht gut aus, aber: ...
NTPD_ADJUST_CMOS_CLOCK="no"
Hier evtl. "yes" eintragen. Dann mach mal folgendes (als root): - Nachschauen, ob ein ntpd Prozess läuft: ps -lfC ntpd - wenn keiner da ist, dann -- rcntpd start -- einige Minuten warten, -- mit ps nachschauen ob der Prozess noch da ist, -- wenn er's nicht is, /var/log/ntpd ansehen und Fehlermeldungen hier posten - sonst, wenn ntp läuft, '/usr/sbin/ntpdc -c peers localhost' eingeben. Das sollte eine Ausgabe der bekannten Zeitquelen geben. Hier sieht das so aus:
remote local st poll reach delay offset disp ======================================================================= =LOCAL(0) 127.0.0.1 10 64 377 0.00000 0.000000 0.03033 =ptbtime2.ptb.de 192.168.0.4 1 1024 377 0.03783 0.001218 0.12177 *ptbtime1.ptb.de 192.168.0.4 1 1024 377 0.03552 0.000029 0.12170 =balrog.xxxx.xxx 192.168.0.4 2 1024 377 0.00026 -0.000296 0.12172
die ptbtime-Server sollten bei dir auftauchen, das erste Zeichen vor dem Namen hat eine besondere Bedeutung. Wenn der ntp sich bei dir weiterhin selbst beendet sollte auf jeden Fall was in der Log_datei stehen. Ansonsten solte man nach einer Weile sehen können ob bzw. warum die Zeitsynchronisation nicht klappt. Arno -- IT-Service Lehmann al@its-lehmann.de Arno Lehmann http://www.its-lehmann.de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Montag, 11. Juni 2007 23:35 schrieb Arno Lehmann:
NTPD_ADJUST_CMOS_CLOCK="no"
Hier evtl. "yes" eintragen.
Dann mach mal folgendes (als root): - Nachschauen, ob ein ntpd Prozess läuft: ps -lfC ntpd - wenn keiner da ist, dann -- rcntpd start -- einige Minuten warten, -- mit ps nachschauen ob der Prozess noch da ist, -- wenn er's nicht is, /var/log/ntpd ansehen und Fehlermeldungen hier posten - sonst, wenn ntp läuft, '/usr/sbin/ntpdc -c peers localhost' eingeben. Das sollte eine Ausgabe der bekannten Zeitquelen geben. Hier sieht das
so aus:
remote local st poll reach delay offset disp ======================================================================= =LOCAL(0) 127.0.0.1 10 64 377 0.00000 0.000000 0.03033 =ptbtime2.ptb.de 192.168.0.4 1 1024 377 0.03783 0.001218 0.12177 *ptbtime1.ptb.de 192.168.0.4 1 1024 377 0.03552 0.000029 0.12170 =balrog.xxxx.xxx 192.168.0.4 2 1024 377 0.00026 -0.000296 0.12172
die ptbtime-Server sollten bei dir auftauchen, das erste Zeichen vor dem Namen hat eine besondere Bedeutung.
Wenn der ntp sich bei dir weiterhin selbst beendet sollte auf jeden Fall was in der Log_datei stehen. Ansonsten solte man nach einer Weile sehen können ob bzw. warum die Zeitsynchronisation nicht klappt.
Hallo Arno, endlich habe ich etwas Zeit gefunden, deine schon vor längerer Zeit beschriebenen Schritte auszuprobieren-und siehe da: wir kommen dem Problem immer näher. Ich kopiere mal einfach das, was ich in die Shell eingegeben habe, hier hinein: noname:/home/christian # ps -lfC ntpd F S UID PID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME CMD 5 S ntp 3217 1 0 75 0 - 1084 - 10:02 ? 00:00:00 /usr/ noname:/home/christian # /usr/sbin/ntpdc -c peers localhost remote local st poll reach delay offset disp ======================================================================= *LOCAL(0) 127.0.0.1 13 64 377 0.00000 0.000000 0.03070 =ptbtime2.ptb.de 192.168.178.21 1 1024 377 0.03236 -132.3509 0.12863 =ptbtime1.ptb.de 192.168.178.21 1 1024 377 0.03294 -166.5927 0.11272 noname:/home/christian # rcntpd start bash: rcntpd: command not found Interessant hier finde ich, dass der Befehl rcntpd gänzlich unbekannt ist und noch interessanter finde ich, dass die Datei /var/log/ntpd ebenfalls nicht existiert. Jetzt kommen wir dem Problem immer näher. @Ralf: Danke für deine Tips, aber ich verstehe dein "Fachchiniesisch" leider nicht. Ich weiß zB. nicht, wie ich "die restrict und die filegen Zeilen auskommentieren" soll. Hab sowas noch nie gemacht und weiß nicht, wie man das macht... Was Berechtigungen sind, weiß ich zum Glück noch :-) hier sind sie: /var/lib/ntp/ntp.drift exisitiert;allerdings unter diesem Pfad: /var/lib/ntp/drift Datei hänge ich dran, steht aber nicht viel drin.. Berechtigung auf /var/lib/ntp: Einträge anzeigen&Öffnen: Alle Schreiben: Benutzer /var/log/ntpstats/ existiert nicht, also auch keine Berechtigungen. Was ich noch versuche ist, ein Update vom NTPD drüberzujagen-vielleicht klappts ja dann... Halte euch auf dem Laufenden! Schöne Sonntagsgrüße, Christian
Hallo, 24.06.2007 12:09,, Christian Pubanz wrote:: ...
Hallo Arno,
endlich habe ich etwas Zeit gefunden, deine schon vor längerer Zeit beschriebenen Schritte auszuprobieren-und siehe da: wir kommen dem Problem immer näher. Ich kopiere mal einfach das, was ich in die Shell eingegeben habe, hier hinein:
noname:/home/christian # ps -lfC ntpd F S UID PID PPID C PRI NI ADDR SZ WCHAN STIME TTY TIME CMD 5 S ntp 3217 1 0 75 0 - 1084 - 10:02 ? 00:00:00 /usr/
Ok, also der ntpd läuft. Das ist schon mal gut.
noname:/home/christian # /usr/sbin/ntpdc -c peers localhost remote local st poll reach delay offset disp ======================================================================= *LOCAL(0) 127.0.0.1 13 64 377 0.00000 0.000000 0.03070 =ptbtime2.ptb.de 192.168.178.21 1 1024 377 0.03236 -132.3509 0.12863 =ptbtime1.ptb.de 192.168.178.21 1 1024 377 0.03294 -166.5927 0.11272
Hmm. hat noch nicht mit einem der PTB-Server syncronisiert. Das sollte allerdings nach einer Weile der Fall sein, dann müsste einer der beiden mit einem * markiert sein.
noname:/home/christian # rcntpd start bash: rcntpd: command not found
Interessant hier finde ich, dass der Befehl rcntpd gänzlich unbekannt ist und noch interessanter finde ich, dass die Datei /var/log/ntpd ebenfalls nicht existiert. Jetzt kommen wir dem Problem immer näher.
Könnten distributionsspezifische Unterschiede sein. Ich hab' hier mit OpenSuse (sp?) 10.2 und SuSE 9.3 rumprobiert...
@Ralf:
Danke für deine Tips, aber ich verstehe dein "Fachchiniesisch" leider nicht. Ich weiß zB. nicht, wie ich "die restrict und die filegen Zeilen auskommentieren" soll. Hab sowas noch nie gemacht und weiß nicht, wie man das macht...
Einfach ein # vor die Zeilen in der Konfigurationsdatei, danach ntpd neu starten.
Was Berechtigungen sind, weiß ich zum Glück noch :-) hier sind sie:
/var/lib/ntp/ntp.drift exisitiert;allerdings unter diesem Pfad: /var/lib/ntp/drift
Datei hänge ich dran, steht aber nicht viel drin..
Berechtigung auf /var/lib/ntp: Einträge anzeigen&Öffnen: Alle Schreiben: Benutzer
/var/log/ntpstats/ existiert nicht, also auch keine Berechtigungen.
Was ich noch versuche ist, ein Update vom NTPD drüberzujagen-vielleicht klappts ja dann...
Auch gut möglich, aber das halte ich für unwahrscheinlich.
Halte euch auf dem Laufenden!
Entscheidend ist bis jetzt dass der ntpd läuft. Wenn der nicht mit einem der PTP-Server syncronisieren mag muss man das noch angehen, aber da hatte ich nie Probleme mit :-) Arno
Schöne Sonntagsgrüße, Christian
-- Arno Lehmann IT-Service Lehmann www.its-lehmann.de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Arno Lehmann, Sonntag, 24. Juni 2007 12:33:
Könnten distributionsspezifische Unterschiede sein. Ich hab' hier mit OpenSuse (sp?) 10.2 und SuSE 9.3 rumprobiert...
Heißt hier = 10.2: rcntp start und nicht rcntpd ... -- Andre Tann -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Sonntag, 24. Juni 2007 12:33 schrieb Arno Lehmann:
Ok, also der ntpd läuft. Das ist schon mal gut. Könnten distributionsspezifische Unterschiede sein. Ich hab' hier mit OpenSuse (sp?) 10.2 und SuSE 9.3 rumprobiert...
Einfach ein # vor die Zeilen in der Konfigurationsdatei, danach ntpd neu starten.
Auch gut möglich, aber das halte ich für unwahrscheinlich.> Entscheidend ist bis jetzt dass der ntpd läuft.
Wenn der nicht mit einem der PTP-Server syncronisieren mag muss man das noch angehen, aber da hatte ich nie Probleme mit :-)
Arno
Hi Arno, hab grad nochmal nachgeforscht und etwas entscheidendes festgestellt. Der NTPD startet beim Booten anscheinend nicht bzw. beendet sich nach dem Bootvorgang (aus welchen Gründen auch immer). Denn wenn ich direkt nach dem Booten rcntp status in die Shell tippe, erscheind unused. Das selbe ist auch, wenn ich /usr/sbin/ntpdc -c peers localhost eintippe, dann erscheint connection refused. Auch im Yast /Runleveleditor steht unter ntp "Aktiv-Nein". Erst wenn ich ihn durch rcntp start manuell starte, läuft er und gibt eine entsprechende Erfolgsmeldung "running" aus. Allerdings scheint er weiter nicht zu syncronisieren; siehe hier: noname:/home/christian # /usr/sbin/ntpdc -c peers localhost remote local st poll reach delay offset disp ======================================================================= *LOCAL(0) 127.0.0.1 10 64 377 0.00000 0.000000 0.03052 =195.244.96.13 192.168.178.21 2 256 377 0.02133 -26.35310 0.15089 Ich bin jetzt mal testweise von den PTB-Servern auf de.pool.ntp.org umgestiegen. Also: 1. Müsste ich hinbekommen, dass der NTPD beim Booten startet, sich nicht beendet und die Zeit syncronisiert. 2. Dass der NTPD in regelmäßigen Abständen der die Uhrzeit überprüft und ggf. korrigiert. Habe eben grade noch in der Boot.log folgendes gefunden: /var/lib/ntp/var/run/ntp/ntpd.pid -u Hängt das event. damit zusammen? Grüße Christian -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Christian Pubanz schrieb:
noname:/home/christian # /usr/sbin/ntpdc -c peers localhost remote local st poll reach delay offset disp ======================================================================= *LOCAL(0) 127.0.0.1 10 64 377 0.00000 0.000000 0.03052 =195.244.96.13 192.168.178.21 2 256 377 0.02133 -26.35310 0.15089
Hallo Christian, was soll "ntpdc -c peers" Dir zeigen (konnte ich Arnos Mail auch nicht entnehmen)? Ich finde "ntpq -p" nicht nur kürzer, sondern auch aussagekräftiger - vorne steht nicht das =, sondern eine Kennung, die die eingeschätzte Qualität des jeweiligen Zeitservers angibt (von *=bevorzugt bis x=scheußlich).
Ich bin jetzt mal testweise von den PTB-Servern auf de.pool.ntp.org umgestiegen.
Dazu sind sie da ;-) Es sei denn, Du hast ein größeres Firmennetzwerk zu versorgen...
Also:
1. Müsste ich hinbekommen, dass der NTPD beim Booten startet, sich nicht beendet und die Zeit syncronisiert. 2. Dass der NTPD in regelmäßigen Abständen der die Uhrzeit überprüft und ggf. korrigiert. Das Letzere ist genau das, was Aufgabe des ntpd ist. Das mit dem Start beim Booten ist allerdings so eine Sache :-( Der Befehl "insserv ntp" sollte in den jeweiligen Runleveln die Links setzen (wie der YaST Runlevel-Editor; wobei "ntp" der Name des Scripts in /etc/init.d ist - SLES 8, SLES 9 und SLES 10 sind da z. B. unterschiedlich: xntpd, ntp, ntpd). Beim nächsten Boot (oder "init 3") sollte der Zeitserver dann starten.
Er startet jedoch *nicht*, wenn die Abweichung der gefundenen Zeitserver von seiner eigenen Zeit eine bestimmte Frist übersteigt[1] :-/. Oder wenn er keine Netzwerkverbindung findet... [1] weswegen ich meinen Firmenzeitserver nach einem Reboot immer noch mal manuell kontrolliere :-(
Habe eben grade noch in der Boot.log folgendes gefunden: /var/lib/ntp/var/run/ntp/ntpd.pid -u
Hängt das event. damit zusammen?
Ja, evtl. ;-) Das sagt erstmal aus, dass der Zeitserver im chroot läuft. Siehe Zeile NTPD_RUN_CHROOTED="yes" in /etc/init.d/ntp Wenn der ntp chrooted läuft, sieht er das mit CHROOT_PREFIX angegebene Verzeichnis als / an. Die Angaben in der /etc/ntp.conf müssen also "addiert" werden. Wenn dort ein "driftfile /var/lib/ntp/drift/ntp.drift" eingetragen ist, der CHROOT_PREFIX auf /var/lib/ntp zeigt, liegt das Driftfile im Ergebnis unter /var/lib/ntp/var/lib/ntp/drift/ntp.drift. Analog wird das PID-file auf "$CHROOT_PREFIX/var/run/ntp/ntpd.pid" gesetzt (in /etc/init.d/ntp).
Grüße
Christian
HTH Werner -- Werner Flamme, Abt. WKDV Helmholtz-Zentrum für Umweltforschung GmbH - UFZ Permoserstr. 15 - 04318 Leipzig Tel.: (0341) 235-3921 - Fax (0341) 235-453921 http://www.ufz.de - eMail: werner.flamme@ufz.de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, 26.06.2007 16:57,, Werner Flamme wrote::
Christian Pubanz schrieb:
noname:/home/christian # /usr/sbin/ntpdc -c peers localhost remote local st poll reach delay offset disp ======================================================================= *LOCAL(0) 127.0.0.1 10 64 377 0.00000 0.000000 0.03052 =195.244.96.13 192.168.178.21 2 256 377 0.02133 -26.35310 0.15089
Hallo Christian,
was soll "ntpdc -c peers" Dir zeigen (konnte ich Arnos Mail auch nicht entnehmen)?
Das ist nur meine Variante zu prüfen ob ntpd läuft und mit Servern syncronisiert.
Ich finde "ntpq -p" nicht nur kürzer, sondern auch aussagekräftiger - vorne steht nicht das =, sondern eine Kennung, die die eingeschätzte Qualität des jeweiligen Zeitservers angibt (von *=bevorzugt bis x=scheußlich).
Ist mir meistens egal :-) ich will nur wissen welche da sind und in Frage kommen könnten. Für das aktuelle Problem scheint mir das auch nicht wichtig zu sein.
Ich bin jetzt mal testweise von den PTB-Servern auf de.pool.ntp.org umgestiegen. Dazu sind sie da ;-) Es sei denn, Du hast ein größeres Firmennetzwerk zu versorgen...
Also: 1. Müsste ich hinbekommen, dass der NTPD beim Booten startet, sich nicht beendet und die Zeit syncronisiert. 2. Dass der NTPD in regelmäßigen Abständen der die Uhrzeit überprüft und ggf. korrigiert. Das Letzere ist genau das, was Aufgabe des ntpd ist. Das mit dem Start beim Booten ist allerdings so eine Sache :-( Der Befehl "insserv ntp" sollte in den jeweiligen Runleveln die Links setzen (wie der YaST Runlevel-Editor; wobei "ntp" der Name des Scripts in /etc/init.d ist - SLES 8, SLES 9 und SLES 10 sind da z. B. unterschiedlich: xntpd, ntp, ntpd). Beim nächsten Boot (oder "init 3") sollte der Zeitserver dann starten.
Er startet jedoch *nicht*, wenn die Abweichung der gefundenen Zeitserver von seiner eigenen Zeit eine bestimmte Frist übersteigt[1] :-/.
Das wird von den SuSE-Startskripten normalerweise durch ein vorneweg durchgeführtes ntpdate gelöst. Und wenn's daran läge dürfte der ntpd auch später nicht starten mögen, ausserndem müsste er dann was loggen (IIRC).
Oder wenn er keine Netzwerkverbindung findet...
Ich *vermute* inzwischen dass das Problem da liegt. Meine Lösung bzw. meine nächsten Schritte wären folgendes: Erstmal überprüfen ob das ntp-Startscript nach dem Netzwerk gestartet werden sollte. In der Shell 'ls /etc/rc.d/rc5.d/S*netw* /etc/rc.d/rc5.d/S*ntp*' eingeben und prüfen dass die Zahl hinter dem S bei network niedriger als bei ntp ist. Ist sie das nicht, dann sind die Required-Start-Angaben in den Startskripten ungünstig. So sehe ich hier bei mir grade dass bei SuSE 9.2 network NICHT Voraussetzung für ntp ist... das ist m.E. falsch. Das liesse sich beheben wenn man in der Zeile "# Required-Start: " im ntp-Startskript noch "network" hinzufügt und mit 'insserv ntpd' den Daemon nochmal aktiviert. Hoffe ich jedenfalls :-) Wenn das obige nicht das Problem ist, dann würde ich eine Zeile mit '/sbin/ifconfig' beim Anfang vom ntp-Startskript enfügen um zu sehen ob das Netzwerk zumindest schon verfügbar ist wenn ntpd gestartet werden soll.
[1] weswegen ich meinen Firmenzeitserver nach einem Reboot immer noch mal manuell kontrolliere :-(
Tja, vor allem wichtig wenn man mehrere Zeitserver betreibt die sich gegenseitig als Server nutzen sollen ;-)
Habe eben grade noch in der Boot.log folgendes gefunden: /var/lib/ntp/var/run/ntp/ntpd.pid -u Hängt das event. damit zusammen?
Ja, evtl. ;-) Das sagt erstmal aus, dass der Zeitserver im chroot läuft. Siehe Zeile NTPD_RUN_CHROOTED="yes" in /etc/init.d/ntp
Wenn der ntp chrooted läuft, sieht er das mit CHROOT_PREFIX angegebene Verzeichnis als / an. Die Angaben in der /etc/ntp.conf müssen also "addiert" werden. Wenn dort ein "driftfile /var/lib/ntp/drift/ntp.drift" eingetragen ist, der CHROOT_PREFIX auf /var/lib/ntp zeigt, liegt das Driftfile im Ergebnis unter /var/lib/ntp/var/lib/ntp/drift/ntp.drift. Analog wird das PID-file auf "$CHROOT_PREFIX/var/run/ntp/ntpd.pid" gesetzt (in /etc/init.d/ntp).
Letztes Mal als ich guckte sah es so aus als würde das Startskript das versuchen richtig zu lösen... und wenn's daran hängt dürfte der spätere Start auch nicht klappen.
Grüße
Christian
HTH Werner
Ebenso, Arno -- Arno Lehmann IT-Service Lehmann www.its-lehmann.de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Dienstag, 26. Juni 2007 20:40 schrieb Arno Lehmann:
Meine Lösung bzw. meine nächsten Schritte wären folgendes: Erstmal überprüfen ob das ntp-Startscript nach dem Netzwerk gestartet werden sollte. In der Shell 'ls /etc/rc.d/rc5.d/S*netw* /etc/rc.d/rc5.d/S*ntp*' eingeben und prüfen dass die Zahl hinter dem S bei network niedriger als bei ntp ist. Ist sie das nicht, dann sind die Required-Start-Angaben in den Startskripten ungünstig. So sehe ich hier bei mir grade dass bei SuSE 9.2 network NICHT Voraussetzung für ntp ist... das ist m.E. falsch.
Das liesse sich beheben wenn man in der Zeile "# Required-Start: " im ntp-Startskript noch "network" hinzufügt und mit 'insserv ntpd' den Daemon nochmal aktiviert. Hoffe ich jedenfalls :-)
Hi Arno, dein oben genannten Befehl kennt mein Shell nicht: noname:/home/christian # ls /etc/rc.d/rc5.d/S*netw* /etc/rc.d/rc5.d/S05network Hab ich das richtig eingetippt? Und welches Startskript meinst du? Grüßle Christian -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, 02.07.2007 15:08,, Christian Pubanz wrote::
Am Dienstag, 26. Juni 2007 20:40 schrieb Arno Lehmann:
Meine Lösung bzw. meine nächsten Schritte wären folgendes: Erstmal überprüfen ob das ntp-Startscript nach dem Netzwerk gestartet werden sollte. In der Shell 'ls /etc/rc.d/rc5.d/S*netw* /etc/rc.d/rc5.d/S*ntp*' eingeben und prüfen dass die Zahl hinter dem S bei network niedriger als bei ntp ist. Ist sie das nicht, dann sind die Required-Start-Angaben in den Startskripten ungünstig. So sehe ich hier bei mir grade dass bei SuSE 9.2 network NICHT Voraussetzung für ntp ist... das ist m.E. falsch.
Das liesse sich beheben wenn man in der Zeile "# Required-Start: " im ntp-Startskript noch "network" hinzufügt und mit 'insserv ntpd' den Daemon nochmal aktiviert. Hoffe ich jedenfalls :-)
Hi Arno,
dein oben genannten Befehl kennt mein Shell nicht:
noname:/home/christian # ls /etc/rc.d/rc5.d/S*netw* /etc/rc.d/rc5.d/S05network
Stimmt soweit. Die Zeile mit *ntp* hätte halt in die gleiche Befehlszeile gemusst... die Nachteile vom automatischen Umbrechen von Mails :-(
Hab ich das richtig eingetippt?
Soweit ja. Und jetzt nochmal 'ls /etc/rc.d/rc5.d/S*ntp*' und dabei sollte dann rauskommen dass ntp NACH network gestartet wird, also eine grössere Zahl hat.
Und welches Startskript meinst du?
Das von ntp... heisst glaube ich ntpd bei dir. Der o.g. Befehl sollte das zeigen. (Das sind übrigens symbolische Links auf das tatsächliche Startskript, was woanders lieget, aber das macht hier nichts.)
Grüßle Christian
Grüßle... hm... du warst das mit dem sonnigen Wochenende im Süden, oder? Neid... Arno -- Arno Lehmann IT-Service Lehmann www.its-lehmann.de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Montag, 2. Juli 2007 18:33 schrieb Arno Lehmann:
Stimmt soweit. Die Zeile mit *ntp* hätte halt in die gleiche Befehlszeile gemusst... die Nachteile vom automatischen Umbrechen von Mails :-( Das von ntp... heisst glaube ich ntpd bei dir. Der o.g. Befehl sollte das zeigen.
(Das sind übrigens symbolische Links auf das tatsächliche Startskript, was woanders lieget, aber das macht hier nichts.) Grüßle... hm... du warst das mit dem sonnigen Wochenende im Süden, oder? Neid...
Hi Arno, ja, jetzt klappts... Um ehrlich zu sein-ich war zu doof zum einzutippen...:-D Aber jetzt sagt mir die Shell das hier: christian@noname:~> ls /etc/rc.d/rc5.d/S*netw* /etc/rc.d/rc5.d/S*ntp* /etc/rc.d/rc5.d/S05network /etc/rc.d/rc5.d/S09ntp Nur zum Verständnis: DER NTPD startet also bevor überhaupt Netzverbindung da ist-kann demnach keinen der angegebenen Server finden und beendet sich wieder-richtig? Dann hätten wir ja das Problem.. Muss jetzt nur noch das Startskript finden und entsprechend abändern.... Ich melde mich wieder! Bis hierher schonmal vielen Dank für deine fachliche Kompetenz... Grüßle Christian PS: Ich hab gesehen, dass du aus dem hohen Norden kommst-tja, wir Süddeutschen haben nunmal die meiste Sonne-ätsch! :-D -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, 02.07.2007 22:54,, Christian Pubanz wrote::
Hi Arno,
ja, jetzt klappts... Um ehrlich zu sein-ich war zu doof zum einzutippen...:-D Aber jetzt sagt mir die Shell das hier:
christian@noname:~> ls /etc/rc.d/rc5.d/S*netw* /etc/rc.d/rc5.d/S*ntp* /etc/rc.d/rc5.d/S05network /etc/rc.d/rc5.d/S09ntp
Nur zum Verständnis: DER NTPD startet also bevor überhaupt Netzverbindung da ist-kann demnach keinen der angegebenen Server finden und beendet sich wieder-richtig?
Nö, leider nicht :-) Die Skripte werden in der Reheinfolge der Zahlen abgearbeitet, also network vor ntp. Das ist völlig richtig soweit. Meine Vermutung ist jetzt, dass, wenn ntpd gestartet wird, das Netzwerk noch nicht fertig ist. Das kann z.B. passieren, wenn die Netzwerkverbindungen selber erst später erzeugt werden (manuelle Einwahl per Modem oder DSL, lange Wartezeit bis die Verbindung steht, oder sonstwas) und wird durch das parallele Starten verschiedener Dienste noch verschärft. Wenn du eine Einwahlverbindung (DSL per DSL-Modem, analog-Modem, oder ISDN) benutzt, sollte ntp eigentlich dann, wenn die Verbindung steht gestartet werden. Such' mal im Listenarchiv nach Details, da gab's letztens was. Wie auch immer, als nächstes würde ich prüfen, ob beim Start von ntp die Netzwerkverbindung zur Verfügung steht. Wenn ntp oder das Startskript selber nicht loggen, macht man das eben selber. Z.B. zwei Zeilen wie /bin/date >> /tmp/ntp-start.log /sbin/ip addr >> /tmp/ntp-start.log in /etc/rc.d/ntp einfügen. Am einfachsten gleich hinter der 1. Zeile, die da lauten sollte #!/bin/bash Dann erstmal das Startskript ausprobieren. In jedem Fall sollte dann die Datei /tmp/ntp-start.log mit passendem Inhalt entstanden sein. Danach mal den Rechner neu starten und wieder die log-Datei ansehen. Möglicherweise findet sich dann, das zum Zeit des ntp-Starts noch kein Netzwerk bereit ist.
Dann hätten wir ja das Problem.. Muss jetzt nur noch das Startskript finden und entsprechend abändern....
:-)
Ich melde mich wieder! Bis hierher schonmal vielen Dank für deine fachliche Kompetenz...
Gern geschehen...
Grüßle Christian
PS: Ich hab gesehen, dass du aus dem hohen Norden kommst
Für die Kieler komme ich aus dem Süden :-)
-tja, wir Süddeutschen haben nunmal die meiste Sonne-ätsch! :-D
Hm... eher an der Ostsee, glaube ich :-) Aber was hier betrifft hast du leider recht - im Mittel gibt's hier wohl so 200 Stunden weniger Sonne im Jahr :-( Arno -- Arno Lehmann IT-Service Lehmann www.its-lehmann.de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Dienstag, 3. Juli 2007 00:13 schrieb Arno Lehmann:
Die Skripte werden in der Reheinfolge der Zahlen abgearbeitet, also network vor ntp. Das ist völlig richtig soweit.
Meine Vermutung ist jetzt, dass, wenn ntpd gestartet wird, das Netzwerk noch nicht fertig ist.
Das kann z.B. passieren, wenn die Netzwerkverbindungen selber erst später erzeugt werden (manuelle Einwahl per Modem oder DSL, lange Wartezeit bis die Verbindung steht, oder sonstwas) und wird durch das parallele Starten verschiedener Dienste noch verschärft.
Wenn du eine Einwahlverbindung (DSL per DSL-Modem, analog-Modem, oder ISDN) benutzt, sollte ntp eigentlich dann, wenn die Verbindung steht gestartet werden. Such' mal im Listenarchiv nach Details, da gab's letztens was.
Wie auch immer, als nächstes würde ich prüfen, ob beim Start von ntp die Netzwerkverbindung zur Verfügung steht. Wenn ntp oder das Startskript selber nicht loggen, macht man das eben selber. Z.B. zwei Zeilen wie /bin/date >> /tmp/ntp-start.log /sbin/ip addr >> /tmp/ntp-start.log in /etc/rc.d/ntp einfügen.
Am einfachsten gleich hinter der 1. Zeile, die da lauten sollte #!/bin/bash
Dann erstmal das Startskript ausprobieren. In jedem Fall sollte dann die Datei /tmp/ntp-start.log mit passendem Inhalt entstanden sein.
Danach mal den Rechner neu starten und wieder die log-Datei ansehen. Möglicherweise findet sich dann, das zum Zeit des ntp-Starts noch kein Netzwerk bereit ist. Hm... eher an der Ostsee, glaube ich :-) Aber was hier betrifft hast du leider recht - im Mittel gibt's hier wohl so 200 Stunden weniger Sonne im Jahr :-(
Hi Arno, so, nun hab ich eine schöne ntp-start.log, die anbei beiliegt. Leider verstehe ich überhaupt nichts von den geloggten Ereignissen. Anbei außerdem mal mein ntp-Startscript zur Ansicht. Jetzt hoffe ich, dass du das entschlüsseln kannst und mir sagen kannst, was nun zu tun ist, um diesen Spuk endlich zu beenden. Ich habs langsam satt, meine Uhr ständig mit ntpdate manuell nachzujustieren....:-) Christian PS: Wahrscheinlich bin ich so depremiert, weils draußen regnet und die Sonne sich jetzt doch verzogen hat... :-(
Hallo, 03.07.2007 11:56,, Christian Pubanz wrote:: ...
Hi Arno,
so, nun hab ich eine schöne ntp-start.log, die anbei beiliegt. Leider verstehe ich überhaupt nichts von den geloggten Ereignissen. Anbei außerdem mal mein ntp-Startscript zur Ansicht.
Jetzt hoffe ich, dass du das entschlüsseln kannst und mir sagen kannst, was nun zu tun ist, um diesen Spuk endlich zu beenden. Ich habs langsam satt, meine Uhr ständig mit ntpdate manuell nachzujustieren....:-)
Kann ich verstehen...
Christian
PS: Wahrscheinlich bin ich so depremiert, weils draußen regnet und die Sonne sich jetzt doch verzogen hat... :-(
Hier ist es nicht schlechter geworden... es regnet immer noch ;-) Also, zum log...
Tue Jul 3 11:34:45 CEST 2007 1: lo: <LOOPBACK,UP,10000> mtu 16436 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo 2: eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop qlen 1000 link/ether 00:30:05:21:53:e6 brd ff:ff:ff:ff:ff:ff
Hier hat die Netzwerkkarte noch keine Adresse, d.h. darüber kann keine Netzwerkverbindumg mit dem ntp-Server laufen.
Tue Jul 3 11:34:59 CEST 2007 1: lo: <LOOPBACK,UP,10000> mtu 16436 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:30:05:21:53:e6 brd ff:ff:ff:ff:ff:ff inet 192.168.178.21/24 brd 192.168.178.255 scope global eth0 inet6 fe80::230:5ff:fe21:53e6/64 scope link valid_lft forever preferred_lft forever
Jetzt hat sie eine... Hast du um 11:34 den Rechner gestartet, bzw. warum gibt's zu dieser Zeit so viele Einträge?
3: sit0: <NOARP> mtu 1480 qdisc noop link/sit 0.0.0.0 brd 0.0.0.0
Das Startskript sieht soweit ganz gut aus, hat aber tatsächlich keine Abhängigkeit aufs Netzwerk. Wenn das das Problem ist müsste ich wissen wie du am Netz hängst - Router vermutlich, oder? Arno -- Arno Lehmann IT-Service Lehmann www.its-lehmann.de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Dienstag, 3. Juli 2007 15:48 schrieb Arno Lehmann:
Jetzt hat sie eine... Hast du um 11:34 den Rechner gestartet, bzw. warum gibt's zu dieser Zeit so viele Einträge? Das Startskript sieht soweit ganz gut aus, hat aber tatsächlich keine Abhängigkeit aufs Netzwerk.
Wenn das das Problem ist müsste ich wissen wie du am Netz hängst - Router vermutlich, oder?
Hi, ich weiß gar nicht mehr, wann ich meinen Rechner angemacht habe, kann um 11:43 Uhr gewesen sein-event. vom Reboot zum Loggen der Scriptereignisse. Ja, ich häng über LAN-Kabel am Router (FritzBox) mit ständiger Netzverbindung über 1&1... Die FBF läuft immer durch-es sei denn, der Strom fällt aus :-) Gruß Christian -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, 03.07.2007 19:22,, Christian Pubanz wrote::
Am Dienstag, 3. Juli 2007 15:48 schrieb Arno Lehmann:
Jetzt hat sie eine... Hast du um 11:34 den Rechner gestartet, bzw. warum gibt's zu dieser Zeit so viele Einträge? Das Startskript sieht soweit ganz gut aus, hat aber tatsächlich keine Abhängigkeit aufs Netzwerk.
Wenn das das Problem ist müsste ich wissen wie du am Netz hängst - Router vermutlich, oder?
Hi,
ich weiß gar nicht mehr, wann ich meinen Rechner angemacht habe, kann um 11:43 Uhr gewesen sein-event. vom Reboot zum Loggen der Scriptereignisse.
Ja, ich häng über LAN-Kabel am Router (FritzBox) mit ständiger Netzverbindung über 1&1... Die FBF läuft immer durch-es sei denn, der Strom fällt aus :-)
Gut... dann vermute ich dass der ntp nicht mag weil er kein Netzwerk hat mit dem er sich verbinden kann. Bzw. zur Zeit des Starts seine Server nicht findet. 1. Versuch Anhilfe zu schaffen wäre im ntp-Startskript bei reuired-start $network hinzuzufügen. Danach mit 'insserv ntp' die Startskript-Reihenfolge neu ermitteln und anlegen lassen, die log-Datei im /tmp-Verzeichnis löschen und nach dem nächsten Neustart ansehen. Dann sollte die Ausgabe eine IP-Adresse von eth0 enthalten, und das könnte genügen dass ntp startet. Arno
Gruß
Christian
-- Arno Lehmann IT-Service Lehmann www.its-lehmann.de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Mittwoch, 4. Juli 2007 00:30 schrieb Arno Lehmann:
1. Versuch Anhilfe zu schaffen wäre im ntp-Startskript bei reuired-start $network hinzuzufügen. Danach mit 'insserv ntp' die Startskript-Reihenfolge neu ermitteln und anlegen lassen, die log-Datei im /tmp-Verzeichnis löschen und nach dem nächsten Neustart ansehen. Dann sollte die Ausgabe eine IP-Adresse von eth0 enthalten, und das könnte genügen dass ntp startet.
Morgen Arno, habe ich gemacht, anbei das veränderte Startscript und die ntp-start.log, die eindeutig zeigt, dass mein PC früher als sonst, eine IP-Adresse von der FBF zugewiesen bekommt, (DHCP) aber der NTP-Daemon trotzdem nicht läuft. Hab alles richtig gemacht-Script verändert, in der Shell insserv ntp-Script vorher ausführbar gemacht usw. Grüßle Christian
Christian Pubanz schrieb:
Am Mittwoch, 4. Juli 2007 00:30 schrieb Arno Lehmann: [ . . . . ] habe ich gemacht, anbei das veränderte Startscript und die ntp-start.log, die eindeutig zeigt, dass mein PC früher als sonst, eine IP-Adresse von der FBF zugewiesen bekommt, (DHCP) aber der NTP-Daemon trotzdem nicht läuft.
hallo ändere in /etc/sysconfig/boot/ RUN_PARALLEL=yes in RUN_PARALLEL=no Gruß Arno (Jung) -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Donnerstag, 5. Juli 2007 11:35 schrieb Arno Jung:
ändere in /etc/sysconfig/boot/
RUN_PARALLEL=yes
in
RUN_PARALLEL=no
Hi Arno 2! Habe deinen Tip versucht, war aber nix... An Arno 1 (Lehmann): Hab nochmal die Ausgabe von ls /etc/rc.d/rc5.d/S*netw* /etc/rc.d/rc5.d/S*ntp* /etc/rc.d/rc5.d/S05network /etc/rc.d/rc5.d/S09ntp Das ist doch die selbe wie vor dem Eingriff ins Startskript, oder? Also scheint sich nichts geändert zu haben... :-( Gruß, Christian -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hi, 05.07.2007 16:39,, Christian Pubanz wrote::
Am Donnerstag, 5. Juli 2007 11:35 schrieb Arno Jung:
ändere in /etc/sysconfig/boot/
RUN_PARALLEL=yes
in
RUN_PARALLEL=no
Hi Arno 2!
Habe deinen Tip versucht, war aber nix...
Schade, wäre auch mein nächster Vorschlag gewesen...
An Arno 1 (Lehmann):
Hab nochmal die Ausgabe von ls /etc/rc.d/rc5.d/S*netw* /etc/rc.d/rc5.d/S*ntp*
/etc/rc.d/rc5.d/S05network /etc/rc.d/rc5.d/S09ntp
Gut.
Das ist doch die selbe wie vor dem Eingriff ins Startskript, oder? Also scheint sich nichts geändert zu haben...
Stimmt, aber es *könnte* sein dass sich im Hintergrund bezüglich der parallelverarbeitung was geändert hat... ich habe das System nie zu durchschauen versucht...
:-(
Mist. Jetzt fällt mir auch nicht mehr viel ein... ausser noch detaillierter manuell zu probieren. Annahme: ntp startet wenn Netzwerk da ist, und läuft dann und alles ist gut. Problem: ntp startet beim Systemstart nicht, und gibt auch weder Bildschrimmeldungen noch log-Einträge aus. Wenn das so stimmt würde ich mal manuell probieren den Systemstart nachzuspielen. Im einfachsten Fall: In runlevel 1 booten (beim bootprompt einfach eine "1" (Eins, nicht l :-) an die Bootloader-Befehlszeile anhängen und Enter drücken. Dann der numerischen Reihenfolge nach die Startskripte für Runlevel 5 aufrufen, wie sie in /etc/rc.d/rc5.d liegen. Nicht direkt, sondern statt /etc/rc.d/rc5.d/S05network wird /etc/rc.d/network start aufgerufen. Wenn das dann geht (weisst du ja schon nach aufruf von ntp und folgender Prüfung) dann kann es m.E. nur ein Timingproblem sein, d.h. das Netzwerk ist noch nicht einsatzbereit wenn ntp gestartet werden soll. Das ließe sich auf mehrerlei Wegen beheben, im simpelsten Fall einfach ein 'sleep 30' an den Anfang des ntp-Startskripts. Fällt jemand anders noch was ein? Arno
Gruß, Christian
-- Arno Lehmann IT-Service Lehmann www.its-lehmann.de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Donnerstag, 5. Juli 2007 23:30 schrieb Arno Lehmann:
Im einfachsten Fall: In runlevel 1 booten (beim bootprompt einfach eine "1" (Eins, nicht l :-) an die Bootloader-Befehlszeile anhängen und Enter drücken.
Dann der numerischen Reihenfolge nach die Startskripte für Runlevel 5 aufrufen, wie sie in /etc/rc.d/rc5.d liegen. Nicht direkt, sondern statt /etc/rc.d/rc5.d/S05network wird /etc/rc.d/network start aufgerufen.
Wenn das dann geht (weisst du ja schon nach aufruf von ntp und folgender Prüfung) dann kann es m.E. nur ein Timingproblem sein, d.h. das Netzwerk ist noch nicht einsatzbereit wenn ntp gestartet werden soll.
Das ließe sich auf mehrerlei Wegen beheben, im simpelsten Fall einfach ein 'sleep 30' an den Anfang des ntp-Startskripts.
Fällt jemand anders noch was ein?
Hi Arno, der Betreff sagt es schon aus, scheinbar ist mein Problem fast gelöst. Zunächst habe ich in Runlevel 1 das network-Startscript aufgerufen (/etc/rc.d/network start). Daraufhin wurde eine nicht zu stoppende Reihe von dieser Meldung ausgegeben: dhcdbd:dbus_svc_init failed: (null) (null) Da diese Meldung laut Google sich nur auf das fehlerhafte Mounten von Datenträgern bezieht und ich das mit NTP nicht in Verbindung bringen konnte, baute ich am Anfang des NTP-Startscripts ein sleep 30 ein. Ergebnis: Der NTP-Daemon startet sich nun scheinbar und läuft auf dem System weiter. Allerdings kann er irgendwie noch keine Server finden-hab mal die ptb-Server wieder hinzugenommen zum Test. Anbei die gemachten Shell-Meldungen: christian@noname:~> /usr/sbin/ntpdc -c peers localhost remote local st poll reach delay offset disp ======================================================================= *LOCAL(0) 127.0.0.1 10 64 77 0.00000 0.000000 0.43401 =mail.syncronisa 192.168.178.21 1 64 77 0.01851 -37.38222 0.43590 christian@noname:~> /usr/sbin/ntpdc -c peers localhost remote local st poll reach delay offset disp ======================================================================= *LOCAL(0) 127.0.0.1 10 64 377 0.00000 0.000000 0.03072 =mail.syncronisa 192.168.178.21 1 128 377 0.01865 -50.43673 0.07298 christian@noname:~> /usr/sbin/ntpdc -c peers localhost remote local st poll reach delay offset disp ======================================================================= *LOCAL(0) 127.0.0.1 10 64 377 0.00000 0.000000 0.03027 =mail.syncronisa 192.168.178.21 1 64 377 0.01851 -85.29220 0.07396 christian@noname:~> /usr/sbin/ntpdc -c peers localhost remote local st poll reach delay offset disp ======================================================================= =LOCAL(0) 127.0.0.1 10 64 3 0.00000 0.000000 1.98438 =ptbtime2.ptb.de 192.168.178.21 1 64 3 0.03259 -107.1304 1.98436 =ptbtime1.ptb.de 192.168.178.21 1 64 3 0.03290 -104.9429 1.98444 =mail.syncronisa 192.168.178.21 1 64 3 0.01828 -104.9087 1.98444 In jedem Fall ist es aber schonmal ein Fortschritt, dass der NTPD "running" zeigt: Checking for network time protocol daemon (NTPD): running Jetzt müssen wir nur noch hinkriegen, dass der NTPD mit einem der Server kommunziert und die Zeit abgleicht. @Ralf Danke auch für deine Mail, aber du siehst ja, dass Arno scheinbar auf der richtigen Fährte war/ist. Kannst du vielleicht sagen, warum der NTPD mit den Servern noch nicht abgleicht? Schonmal jetzt vielen Dank an die Mailingliste für die geleistete Hilfe in einem nicht so leichten Fall... Viele Grüße und ein schönes, sonniges Wochenende! (Ja, wir haben wieder Sonne! :-) Christian -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Danke auch für deine Mail, aber du siehst ja, dass Arno scheinbar auf der richtigen Fährte war/ist. Kannst du vielleicht sagen, warum der NTPD mit den Servern noch nicht abgleicht?
Schonmal jetzt vielen Dank an die Mailingliste für die geleistete Hilfe in einem nicht so leichten Fall...
Hallo Christian es ist einfacher, wenn Du direkt auf meine Mails antwortest. Bei komplexen Themen, bei denen die Fehlerursache bzw. der Lösungsweg noch nicht klar ersichtlich ist, kann es sein, daß es sich mehrere Zweige innerhalb eines Threads ergeben. Deine Antwort an mich am Ende einer lange Diskussion mit Arno habe ich wirklich nur zufällig gefunden. Zu Deiner Antwort: Tatsache ist: 1. Deine Konfigurationsdatei /etc/ntp.conf passt nicht zu openSUSE 10.2. Du hast mir in einer anderen Mail bestätigt, daß Dateien auf die dort verwiesen wird nicht existieren. Das gleichnamige Dateien in einem anderen Verzeichnissen liegen ist irelevant. Es werden Dateien mit dem angegebenen Pfad gesucht. 2. Ohne tiefere Kenntnis von NTP bin ich mir sicher, daß Deine Datei /etc/ntp.conf eine Beispieldatei ist, die dafür geignet ist einen (sehr) restriktiven NTP Server aufzusetzen. Ich gehe mal davon aus, daß Du dieses nicht vorhast. Die Pfade in den Dateien deuten darauf hin, daß es sich um Beispiele von ntp.org handeln könnte (siehe 1.) 3. Dein Problem mit der abweichenden Systemzeit läßt sich vermutlich mit einem funktionierenden NTP Client lösen. Die Probleme sind aber wahrscheinlich auch unabhängig von NTP zu lösen. Desweiteren kannst Du in weitere Fallen (auch mit NTP) laufen, wenn Du ein Dualboot System mit Windows hast. Antworte zu dem Thema bitte auf meine Mail vom 2007.07.06 bzgl. cat /etc/adjtime cat /var/lib/ntp/drift Die Abhängigkeiten zwischn adjtime und NTP sind mir auch nicht 100 prozentig klar, deshalb sichere bitte auf alle Fälle die Informationen aus den Dateien bevor Du das folgende ausführst. Zu Deinem NTP Problem teste bitte mal folgendes: Führe in eine root Konsole aus:# rcntp stop Benenne die Dateien /etc/ntp.conf /etc/sysconfig/etc jeweils in *.bak um Kopiere die anghängten Dateien passend zu den obigen Namen nach /etc /etc/sysconfig Passe die Berechtigungen, Owner und Gruppe wie folgt an: -rw-r----- 1 root ntp 2132 Jul 8 21:43 /etc/ntp.conf -rw-r--r-- 1 root root 2868 Jul 8 21:43 /etc/sysconfig/ntp Falls Dir nicht klar ist wie, frag ruhig zurück. Öffne eine zweite Konsole als root und führe aus: tail -f /var/log/ntp Führe in in einer anderen (der ersten) Konsole aus: rcntp start Beobachte in der zweiten Konsole, (tail) ob Dein Rechner sich mit einem anderen Server als "LOCAL(0), stratum 10" synchronisiert. Das kann lange dauern. Eigene Erfahrungen haben ergeben, daß eine neue Synchronisation erst nach über eine Stunde erfolgen kann. Wenn dann alles ok ist, super. Falls nicht, schick mal nach zwei Stunden die Ausgabe von: ntpq -p -- Antworten bitte nur in die Mailingliste! PMs bitte an: listreply (@) arndt-on-line (.) de
Am Sonntag, 8. Juli 2007 23:54 schrieb Ralf Arndt:
es ist einfacher, wenn Du direkt auf meine Mails antwortest. Bei komplexen Themen, bei denen die Fehlerursache bzw. der Lösungsweg noch nicht klar ersichtlich ist, kann es sein, daß es sich mehrere Zweige innerhalb eines Threads ergeben. Deine Antwort an mich am Ende einer lange Diskussion mit Arno habe ich wirklich nur zufällig gefunden.
Zu Deiner Antwort: Tatsache ist:
1. Deine Konfigurationsdatei /etc/ntp.conf passt nicht zu openSUSE 10.2. Du hast mir in einer anderen Mail bestätigt, daß Dateien auf die dort verwiesen wird nicht existieren. Das gleichnamige Dateien in einem anderen Verzeichnissen liegen ist irelevant. Es werden Dateien mit dem angegebenen Pfad gesucht.
2. Ohne tiefere Kenntnis von NTP bin ich mir sicher, daß Deine Datei /etc/ntp.conf eine Beispieldatei ist, die dafür geignet ist einen (sehr) restriktiven NTP Server aufzusetzen. Ich gehe mal davon aus, daß Du dieses nicht vorhast. Die Pfade in den Dateien deuten darauf hin, daß es sich um Beispiele von ntp.org handeln könnte (siehe 1.)
3. Dein Problem mit der abweichenden Systemzeit läßt sich vermutlich mit einem funktionierenden NTP Client lösen. Die Probleme sind aber wahrscheinlich auch unabhängig von NTP zu lösen. Desweiteren kannst Du in weitere Fallen (auch mit NTP) laufen, wenn Du ein Dualboot System mit Windows hast. Antworte zu dem Thema bitte auf meine Mail vom 2007.07.06 bzgl. cat /etc/adjtime cat /var/lib/ntp/drift Die Abhängigkeiten zwischn adjtime und NTP sind mir auch nicht 100 prozentig klar, deshalb sichere bitte auf alle Fälle die Informationen aus den Dateien bevor Du das folgende ausführst.
Hallo Ralf, zunächst sorry für meine untergegangene Antwort! Danke für deine Tips und deine Ratschläge. Ich schicke dir hier zunächst die Ausgabe von cat: hristian@noname:~> cat /etc/adjtime 0.670637 1183966785 0.000000 1183966785 LOCAL christian@noname:~> cat /var/lib/ntp/drift cat: /var/lib/ntp/drift: Datei oder Verzeichnis nicht gefunden christian@noname:~> cat /var/lib/ntp/drift cat: /var/lib/ntp/drift: Ist ein Verzeichnis christian@noname:~> Die andere Sache teste ich jetzt aus; ich melde mich dann nochmal gesondert! Grüße Christian -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Montag, 9. Juli 2007 10:16 schrieb Christian Pubanz:
Am Sonntag, 8. Juli 2007 23:54 schrieb Ralf Arndt:
[...] 3. Dein Problem mit der abweichenden Systemzeit läßt sich vermutlich mit einem funktionierenden NTP Client lösen. Die Probleme sind aber wahrscheinlich auch unabhängig von NTP zu lösen. Desweiteren kannst Du in weitere Fallen (auch mit NTP) laufen, wenn Du ein Dualboot System mit Windows hast. Antworte zu dem Thema bitte auf meine Mail vom 2007.07.06 bzgl. cat /etc/adjtime cat /var/lib/ntp/drift Die Abhängigkeiten zwischn adjtime und NTP sind mir auch nicht 100 prozentig klar, deshalb sichere bitte auf alle Fälle die Informationen aus den Dateien bevor Du das folgende ausführst.
Hallo Ralf,
zunächst sorry für meine untergegangene Antwort!
Danke für deine Tips und deine Ratschläge.
Ich schicke dir hier zunächst die Ausgabe von cat:
hristian@noname:~> cat /etc/adjtime 0.670637 1183966785 0.000000
Hmm, der erste Wert ist nach meinem Kenntnisstand die tagliche Abweichung Deiner Hardwareuhr von der rellen Zeit in Sekunden (jedenfalls die Abweichung, an die Linux glaubt). Bei Deinem Symptom (korrekte Zeit bei Systemstart, Uhr wird im Betrieb deutlich vorgestellt) hätte ich hier einen wesentlichen höheren Wert erwartet. Eine Abweichung von weniger als 1 Sekunde/Tag sollte das aber nicht verursachen. Evtl. bringt meine Korrektur unten zu der anderen Datei etwas Erleuchtung.
1183966785 LOCAL
christian@noname:~> cat /var/lib/ntp/drift cat: /var/lib/ntp/drift: Datei oder Verzeichnis nicht gefunden christian@noname:~> cat /var/lib/ntp/drift cat: /var/lib/ntp/drift: Ist ein Verzeichnis christian@noname:~>
Mein Fehler, es sollte heissen: cat /var/lib/ntp/drift/ntp.drift Das ist die bei Dir existierende drift Datei. Die andere ist diejenige, welche in Deiner ntp.conf eingetragen war und nicht existiert. Grüße Ralf -- Antworten bitte nur in die Mailingliste! PMs bitte an: listreply (@) arndt-on-line (.) de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Montag, 9. Juli 2007 11:16 schrieb Ralf Arndt:
Hmm, der erste Wert ist nach meinem Kenntnisstand die tagliche Abweichung Deiner Hardwareuhr von der rellen Zeit in Sekunden (jedenfalls die Abweichung, an die Linux glaubt). Bei Deinem Symptom (korrekte Zeit bei Systemstart, Uhr wird im Betrieb deutlich vorgestellt) hätte ich hier einen wesentlichen höheren Wert erwartet. Eine Abweichung von weniger als 1 Sekunde/Tag sollte das aber nicht verursachen. Evtl. bringt meine Korrektur unten zu der anderen Datei etwas Erleuchtung. Mein Fehler, es sollte heissen: cat /var/lib/ntp/drift/ntp.drift Das ist die bei Dir existierende drift Datei. Die andere ist diejenige, welche in Deiner ntp.conf eingetragen war und nicht existiert.
Hallo Ralf, sorry, dass ich mich erst jetzt melden kann, aber ich hab bei der Aktion deine ntp.conf in mein eigenes System einzusetzen wohl irgendwelche Rechte falsch gesetzt-weiß nicht mehr genau, was ich da gemacht habe... Jedenfalls kam ich nur noch als root ins SUSE rein und das x-window System war komplett ausgefallen... Im Zuge dessen habe ich jetzt SUSE komplett neu installiert; habe also die aktuellste SUSE-Version nun drauf und bin mit dem NTP ein Stück weitergekommen. Inzwischen holt er sich beim Booten problemlos von de.pool.ntp.org die Zeit und gleicht diese ab. Allerdings beendet er sich nach diesem einmaligen Abgleich-anbei die entsprechende log-Datei. Sorry Ralf, aber nachdem was ich so inzwischen gelernt habe, kann das mit der drift-Datei eigentlich nicht mehr zusammen hängen, oder? Vielleicht haben ja auch Programmierer von SUSE meine Postings mitgelesen und haben das inzwischen entsprechend berichtigt. Ich glaube, dass es jetzt nur noch an dem NTPD hängt. Gibt's irgendwie die Möglichkeit, beim NTPD Einstellungen vorzunehmen; wenn ja, wie? Oder bin ich da auf dem ganz falschen Dampfer? *grins* Grüße, Christian
Am Mittwoch, 11. Juli 2007 15:03 schrieb Christian Pubanz:
sorry, dass ich mich erst jetzt melden kann, aber ich hab bei der Aktion deine ntp.conf in mein eigenes System einzusetzen wohl irgendwelche Rechte falsch gesetzt-weiß nicht mehr genau, was ich da gemacht habe... Jedenfalls kam ich nur noch als root ins SUSE rein und das x-window System war komplett ausgefallen...
Uups, wo hast Du denn Rechte gesetzt, direkt auf die Datei, oder weiter oben in der Dateistruktur?
Im Zuge dessen habe ich jetzt SUSE komplett neu installiert; habe also die aktuellste SUSE-Version nun drauf...
Ich hoffe die 10.2. Oder hast Du die 10.3 Alpha installiert? Die ist nämlich noch in der Entwicklung und nicht für produktive Rechner geeignet.
...und bin mit dem NTP ein Stück weitergekommen. Inzwischen holt er sich beim Booten problemlos von de.pool.ntp.org die Zeit und gleicht diese ab. Allerdings beendet er sich nach diesem einmaligen Abgleich-anbei die entsprechende log-Datei.
Ich sehe da aber nur Synchronisationen mit Deiner internen Uhr, nicht mit einem externen Server, also stimmt da etwas noch nicht. Wie hast Du auf dem neuen System NTP konfiguriert, manuell die Dateien editiert, oder mit Yast?
Sorry Ralf, aber nachdem was ich so inzwischen gelernt habe, kann das mit der drift-Datei eigentlich nicht mehr zusammen hängen, oder?
Denke ich nun auch nicht mehr. Es war halt so, daß die Angaben in der ntp.conf nicht mit Deiner Umgebung übereinstimmten. Außerdem lässt das Verstellen der Rechneruhr im Betrieb auf eine zu hohe Drift schließen.
Vielleicht haben ja auch Programmierer von SUSE meine Postings mitgelesen und haben das inzwischen entsprechend berichtigt.
Wenn Du die 10.2 drauf hast, glaube ich das nicht. Ich kann an Update von xntp oder yast-ntp in den letzten tagen erinnern.
Ich glaube, dass es jetzt nur noch an dem NTPD hängt. Gibt's irgendwie die Möglichkeit, beim NTPD Einstellungen vorzunehmen; wenn ja, wie?
Oder bin ich da auf dem ganz falschen Dampfer? *grins*
Apropos Dampfer: Ich muss zum Bahnhof. Ich hab heute nämlich keine Lust auf Überstunden. Schick nochmal die bekannten Konfigurationsdateien. Ralf -- Antworten bitte nur in die Mailingliste! PMs bitte an: listreply (@) arndt-on-line (.) de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Mittwoch, 11. Juli 2007 16:37 schrieb Ralf Arndt:
Uups, wo hast Du denn Rechte gesetzt, direkt auf die Datei, oder weiter oben in der Dateistruktur? Ich hoffe die 10.2. Oder hast Du die 10.3 Alpha installiert? Die ist nämlich noch in der Entwicklung und nicht für produktive Rechner geeignet. Ich sehe da aber nur Synchronisationen mit Deiner internen Uhr, nicht mit einem externen Server, also stimmt da etwas noch nicht.
Wie hast Du auf dem neuen System NTP konfiguriert, manuell die Dateien editiert, oder mit Yast? Denke ich nun auch nicht mehr. Es war halt so, daß die Angaben in der ntp.conf nicht mit Deiner Umgebung übereinstimmten. Außerdem lässt das Verstellen der Rechneruhr im Betrieb auf eine zu hohe Drift schließen. Wenn Du die 10.2 drauf hast, glaube ich das nicht. Ich kann an Update von xntp oder yast-ntp in den letzten tagen erinnern. Apropos Dampfer: Ich muss zum Bahnhof. Ich hab heute nämlich keine Lust auf Überstunden.
Schick nochmal die bekannten Konfigurationsdateien.
Hallo Ralf, ich glaube, ich hab für den ganzen Ordner die Rechte geändert-ich weiß nur noch, dass die Meldung "keine Berechtigung für /etc/bash.bin" erschien... Aber das war ganz klar mein Fehler... Aber egal-ich hab's ja wieder neu und das ist ja auch in Ordnung! Außerdem wollte ich die ganze Zeit schon updaten, von daher war der Fehler auch vielleicht gewollt... :-) Natürlich habe ich SUSE 10.2! Ich installiere grundsätzlich keine Software, die noch nicht offiziell freigegeben ist. Ich leite meine Vermutung mit dem Abgleich aus einer in boot.msg erschienen Meldung, die vor meiner Neuinstallation so nicht zu lesen war: Try to get initial date and time via NTP from de.pool.ntp.org done Das heißt ja, dass er zum Server Kontakt aufgenommen und sich die Uhrzeit erfolgreich geholt hat... Ich hab NTP über Yast eingerichtet; manuell hab ich bisher eigentlich nichts gemacht. Auf jeden Fall sende ich anbei die Konfigurationsdateien sowie die log-Dateien, die auch sehr hilfreich sein können, oder ? :-D Grüße, Christian PS: Hoffentlich hast du deinen Zug noch erwischt-solang die Lockführer nicht streiken (und das dürfen sie ja momentan nicht:-) ) hast du stets gute Chancen auf einen fahrenden Zug:-) Schönen Feierabend!
Am Mittwoch, 11. Juli 2007 17:29 schrieb Christian Pubanz:
ich glaube, ich hab für den ganzen Ordner die Rechte geändert-ich weiß nur noch, dass die Meldung "keine Berechtigung für /etc/bash.bin" erschien... Aber das war ganz klar mein Fehler...
Übel, das hätte man zwar evtl. mit viel Kleinarbeit retten können. Aber wenn Du das rekursiv gemacht hast wäre der Aufwand vermutlich erheblich gewesen.
Aber egal-ich hab's ja wieder neu und das ist ja auch in Ordnung! Außerdem wollte ich die ganze Zeit schon updaten, von daher war der Fehler auch vielleicht gewollt... :-)
Natürlich habe ich SUSE 10.2! Ich installiere grundsätzlich keine Software, die noch nicht offiziell freigegeben ist.
In Deiner Ausgangsmail schriebst Du bereits von "meinem SUSE 10.2-System". Deshalb hat mich Deine Bemerkung zum Aktualisieren irritiert.
Ich leite meine Vermutung mit dem Abgleich aus einer in boot.msg erschienen Meldung, die vor meiner Neuinstallation so nicht zu lesen war:
Try to get initial date and time via NTP from de.pool.ntp.org done
Die Betonung liegt wohl auf "Try". Wenn NTP die Zeit von einem externen NTP Server erhalten hat, siehst Du das auch in /var/log/ntp. Hier ein Beispiel: 11 Jul 20:50:20 ntpd[4362]: synchronized to LOCAL(0), stratum 10 11 Jul 20:50:20 ntpd[4362]: kernel time sync enabled 0001 11 Jul 20:51:25 ntpd[4362]: synchronized to 195.34.187.132, stratum 2
Das heißt ja, dass er zum Server Kontakt aufgenommen und sich die Uhrzeit erfolgreich geholt hat...
Anscheinend eben nicht.
Ich hab NTP über Yast eingerichtet; manuell hab ich bisher eigentlich nichts gemacht.
In Yast gibt es einen Schalter um den eingetragenen Server zu testen. Was gibt der aus?
Auf jeden Fall sende ich anbei die Konfigurationsdateien sowie die log-Dateien, die auch sehr hilfreich sein können, oder ? :-D
Also versuchen wir es mal: Im Grunde hast Du zwei fast unabhängige Komponenten: 1. Einen NTP Client, der keine Zeit von dem externen Server erhält. 2. Einen NTP Server (ntpd), der sich laut ntp.log regelmäßig beendet und nach einiger Zeit neu startet. Oder hast Du den NTP Server oder den ganzen Rechner zwischen den einzelnen Einträgen im ntp.log neu gestartet? Zu 1.: Das scheint das Hauptproblem zu sein. Was sagt ping de.pool.ntp.org - Wird der Name auf eine IP Adresse aufgelöst? - Erhälst Du eine Antwort von dem Server? - Interssant ist hierzu auch die Antwort auf meine Frage oben zum Test des Servers in Yast. Zu 2. Nach der Beschreibung zu NTPD_INITIAL_NTPDATE in /etc/sysconfig/ntp verlangt Dein Server zunächst eine gültige Zeit von dem angegebenen Server zu erhalten. ntpd beendet sich vermutlich, da genau dieses nicht funktioniert (siehe "1."). Ändern des Wertes auf "" wird vermutlich verhindern, daß der ntpd sich beendet. Da Du aber vermutlich keinen eigenen NTP Server brauchst, wird das eher ein kosmetisches Problem sein.
Grüße, Christian
PS: Hoffentlich hast du deinen Zug noch erwischt-solang die Lockführer nicht streiken (und das dürfen sie ja momentan nicht:-) ) hast du stets gute Chancen auf einen fahrenden Zug:-)
Den Zug habe ich erwischt. Was den Streik betrifft bin ich zerrissen zwischen Egoismus und Verständnis. Gute Nacht Ralf Auch ein PS: Antworte bitte auf einzelne Aspekte/Fragen direkt im Text, anstatt alle Antworten unten zu sammeln. -- Antworten bitte nur in die Mailingliste! PMs bitte an: listreply (@) arndt-on-line (.) de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, auch wenn das nicht das Kernthema Thema dieses Threads ist, ich hatte mal danach gesucht und es wieder aufgegeben: Kann man den ntp-Daemon dazu bringen in fixen Zeitabständen oder zu bestimmten Zeitpunkten sich zu synchronisieren - wenn ja wie? Wenn ein pc 24/7 läuft, sehe ich dass uU lange nix passiert, und ich würde das gerne steuern können .. Danke - und sorry for part-capturing. Calli -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Donnerstag, 12. Juli 2007 09:12 schrieb gooly@gmx.at:
Hallo,
auch wenn das nicht das Kernthema Thema dieses Threads ist, ich hatte mal danach gesucht und es wieder aufgegeben: Kann man den ntp-Daemon dazu bringen in fixen Zeitabständen oder zu bestimmten Zeitpunkten sich zu synchronisieren - wenn ja wie?
Wenn ein pc 24/7 läuft, sehe ich dass uU lange nix passiert, und ich würde das gerne steuern können ..
Versuch mal einen cron Job mit: rcntp force-reload Grüße Ralf -- Antworten bitte nur in die Mailingliste! PMs bitte an: listreply (@) arndt-on-line (.) de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Donnerstag, 12. Juli 2007 schrieb Ralf Arndt:
Am Donnerstag, 12. Juli 2007 09:12 schrieb gooly@gmx.at:
Hallo,
auch wenn das nicht das Kernthema Thema dieses Threads ist, ich hatte mal danach gesucht und es wieder aufgegeben: Kann man den ntp-Daemon dazu bringen in fixen Zeitabständen oder zu bestimmten Zeitpunkten sich zu synchronisieren - wenn ja wie?
Wenn ein pc 24/7 läuft, sehe ich dass uU lange nix passiert, und ich würde das gerne steuern können ..
Versuch mal einen cron Job mit: rcntp force-reload hahmm, daran dachte ich nicht, war fixiert auf die unbekannte, geniale Zeile in der ntp.conf. :)
Grüße Ralf
Danke, Ralf -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Mittwoch, 11. Juli 2007 23:25 schrieb Ralf Arndt:
Zu 1.: Das scheint das Hauptproblem zu sein. Was sagt ping de.pool.ntp.org - Wird der Name auf eine IP Adresse aufgelöst? - Erhälst Du eine Antwort von dem Server? - Interssant ist hierzu auch die Antwort auf meine Frage oben zum Test des Servers in Yast.
Zu 2. Nach der Beschreibung zu NTPD_INITIAL_NTPDATE in /etc/sysconfig/ntp verlangt Dein Server zunächst eine gültige Zeit von dem angegebenen Server zu erhalten. ntpd beendet sich vermutlich, da genau dieses nicht funktioniert (siehe "1."). Ändern des Wertes auf "" wird vermutlich verhindern, daß der ntpd sich beendet. Da Du aber vermutlich keinen eigenen NTP Server brauchst, wird das eher ein kosmetisches Problem sein. Auch ein PS: Antworte bitte auf einzelne Aspekte/Fragen direkt im Text, anstatt alle Antworten unten zu sammeln.
Hallo Ralf, sorry, wenn ich mich über dein PS hinwegsetze, aber ich hab mich an diese Art des Antwortens gewöhnt-außerdem hab ich bisher mit dieser Methode gute Erfahrungen gemacht. Oder verstößt das gegen die Nettiqette der Mailingliste? Zum Thema: Der Schalter in Yast sagt: "Der Server ist erreichbar und antwortet". Der Ping gibt aus: christian@christian:~> ping de.pool.ntp.org PING de.pool.ntp.org (213.203.226.170) 56(84) bytes of data. 64 bytes from ceres.sternbauer.de (213.203.226.170): icmp_seq=1 ttl=56 time=18.0 ms 64 bytes from ceres.sternbauer.de (213.203.226.170): icmp_seq=2 ttl=56 time=17.2 ms 64 bytes from ceres.sternbauer.de (213.203.226.170): icmp_seq=3 ttl=56 time=18.0 ms 64 bytes from ceres.sternbauer.de (213.203.226.170): icmp_seq=4 ttl=56 time=17.6 ms 64 bytes from ceres.sternbauer.de (213.203.226.170): icmp_seq=5 ttl=56 time=17.1 ms 64 bytes from ceres.sternbauer.de (213.203.226.170): icmp_seq=6 ttl=56 time=17.2 ms --- de.pool.ntp.org ping statistics --- 6 packets transmitted, 6 received, 0% packet loss, time 5013ms rtt min/avg/max/mdev = 17.128/17.555/18.076/0.401 ms Ich erhalte also eine Antwort vom Server. Seit 2 Tagen ist aber folgendes-vielleicht hängt das damit zusammen: Immer, wenn ich den PC längere Zeit nicht betreibe (also nachts oder wenn ich unterwegs bin) drehe ich aus Sicherheitsgründen den Strom komplett ab, damit nichts passiert. War auch bisher kein Problem-seit vorgestern jedoch meldet sich, wenn der PC wieder anfährt, das BIOS mit folgender Meldung: System configuration data updated ERROR 0271 check date and time settings WARNING 0251 system COMS checksum bad-default configuration used (Ich hoffe, ich habs richtig abgeschrieben). Nach dieser Meldung sind alle spezifischen BIOS-Einstellungen (ua. Datum/Zeit) verstellt, welche ich dann manuell wieder einstellen muss. Danach läufts jedoch ganz normal. In div. Foren führte man diese Meldung auf eine leere BIOS-Batterie zurück. Aber ich habe erst vor ca. 3 Monaten eine ganz neue Batterie eingesetzt-sie kann doch nicht ernsthaft jetzt schon wieder leer sein, oder? Ich vermute eher die NTP-Linux-Geschichte dahinter kann mir aber keinen Reim darauf machen. Viele Grüße und ein schönes HEIßES Wochenende (35 °C-yes:-) ) Christian -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, 13.07.2007 14:12,, Christian Pubanz wrote::
Am Mittwoch, 11. Juli 2007 23:25 schrieb Ralf Arndt:
Zu 1.: Das scheint das Hauptproblem zu sein. Was sagt ping de.pool.ntp.org - Wird der Name auf eine IP Adresse aufgelöst? - Erhälst Du eine Antwort von dem Server? - Interssant ist hierzu auch die Antwort auf meine Frage oben zum Test des Servers in Yast.
Zu 2. Nach der Beschreibung zu NTPD_INITIAL_NTPDATE in /etc/sysconfig/ntp verlangt Dein Server zunächst eine gültige Zeit von dem angegebenen Server zu erhalten. ntpd beendet sich vermutlich, da genau dieses nicht funktioniert (siehe "1."). Ändern des Wertes auf "" wird vermutlich verhindern, daß der ntpd sich beendet. Da Du aber vermutlich keinen eigenen NTP Server brauchst, wird das eher ein kosmetisches Problem sein. Auch ein PS: Antworte bitte auf einzelne Aspekte/Fragen direkt im Text, anstatt alle Antworten unten zu sammeln.
Hallo Ralf,
sorry, wenn ich mich über dein PS hinwegsetze, aber ich hab mich an diese Art des Antwortens gewöhnt-außerdem hab ich bisher mit dieser Methode gute Erfahrungen gemacht. Oder verstößt das gegen die Nettiqette der Mailingliste?
Hmm... ja :-) Nicht explizit, aber ich z.B. finde es deutlich einfacher den Text von oben nach unten überfliegen zu können und dann die einzelnen Diskussionsstränge zusammenhängend zu beantworten.
Zum Thema:
Der Schalter in Yast sagt: "Der Server ist erreichbar und antwortet". Der Ping gibt aus:
christian@christian:~> ping de.pool.ntp.org PING de.pool.ntp.org (213.203.226.170) 56(84) bytes of data. 64 bytes from ceres.sternbauer.de (213.203.226.170): icmp_seq=1 ttl=56 time=18.0 ms 64 bytes from ceres.sternbauer.de (213.203.226.170): icmp_seq=2 ttl=56 time=17.2 ms 64 bytes from ceres.sternbauer.de (213.203.226.170): icmp_seq=3 ttl=56 time=18.0 ms 64 bytes from ceres.sternbauer.de (213.203.226.170): icmp_seq=4 ttl=56 time=17.6 ms 64 bytes from ceres.sternbauer.de (213.203.226.170): icmp_seq=5 ttl=56 time=17.1 ms 64 bytes from ceres.sternbauer.de (213.203.226.170): icmp_seq=6 ttl=56 time=17.2 ms
--- de.pool.ntp.org ping statistics --- 6 packets transmitted, 6 received, 0% packet loss, time 5013ms rtt min/avg/max/mdev = 17.128/17.555/18.076/0.401 ms
Ich erhalte also eine Antwort vom Server.
Seit 2 Tagen ist aber folgendes-vielleicht hängt das damit zusammen:
Immer, wenn ich den PC längere Zeit nicht betreibe (also nachts oder wenn ich unterwegs bin) drehe ich aus Sicherheitsgründen den Strom komplett ab, damit nichts passiert. War auch bisher kein Problem-seit vorgestern jedoch meldet sich, wenn der PC wieder anfährt, das BIOS mit folgender Meldung:
System configuration data updated ERROR 0271 check date and time settings WARNING 0251 system COMS checksum bad-default configuration used
(Ich hoffe, ich habs richtig abgeschrieben).
Nach dieser Meldung sind alle spezifischen BIOS-Einstellungen (ua. Datum/Zeit) verstellt, welche ich dann manuell wieder einstellen muss. Danach läufts jedoch ganz normal.
In div. Foren führte man diese Meldung auf eine leere BIOS-Batterie zurück. Aber ich habe erst vor ca. 3 Monaten eine ganz neue Batterie eingesetzt-sie kann doch nicht ernsthaft jetzt schon wieder leer sein, oder?
Doch, kann sein. Wenn die Batterie vorher schon zwei Jahre rumlag z.B. Jedenfalls kann das ganz prima erklären warum die Zeit der Hardware-Uhr extrem ungenau läuft und in der Folge auch ntp Probleme bekommt.
Ich vermute eher die NTP-Linux-Geschichte dahinter kann mir aber keinen Reim darauf machen.
Glaub' ich weniger. Ich habe noch nie ein nicht absichtlich Schaden verursachendes Programm gesehen dass das CMOS-Setup vermurkst, und ntp macht das in allen Fällen die ich kenne /und das sind einige auf verschiedenster Hardware) auch nicht.
Viele Grüße und ein schönes HEIßES Wochenende (35 °C-yes:-) )
Mal sehen... zumindest regnet es schon mehrere Stunden lang hier nicht mehr... Arno
Christian
-- Arno Lehmann IT-Service Lehmann www.its-lehmann.de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Freitag, 13. Juli 2007 16:31 schrieb Arno Lehmann:
Hallo,
13.07.2007 14:12,, Christian Pubanz wrote::
Am Mittwoch, 11. Juli 2007 23:25 schrieb Ralf Arndt:
Auch ein PS: Antworte bitte auf einzelne Aspekte/Fragen direkt im Text, anstatt alle Antworten unten zu sammeln.
Hallo Ralf,
sorry, wenn ich mich über dein PS hinwegsetze, aber ich hab mich an diese Art des Antwortens gewöhnt-außerdem hab ich bisher mit dieser Methode gute Erfahrungen gemacht. Oder verstößt das gegen die Nettiqette der Mailingliste?
Hmm... ja :-)
Nicht explizit, aber ich z.B. finde es deutlich einfacher den Text von oben nach unten überfliegen zu können und dann die einzelnen Diskussionsstränge zusammenhängend zu beantworten.
Doch auch explizit. Viele produzieren auf der Liste ungern gesehenen TOFU (Text Oben, Fullquote Unten). Christians mails sind das genaue Gegenteil (Text unten, Full Quote oben) mit dem gleichen Effekt. Man muß durch eine vllt. sehr lange mail scrollen, um zu lesen worauf sich die jeweilige Antwort bezieht. @Christian: Gute Hinweise zum Umgang mit mailinglisten findest Du unter <http://learn.to/quote>
Zum Thema:
Der Schalter in Yast sagt: "Der Server ist erreichbar und antwortet". Der Ping gibt aus:
christian@christian:~> ping de.pool.ntp.org PING de.pool.ntp.org (213.203.226.170) 56(84) bytes of data. 64 bytes from ceres.sternbauer.de (213.203.226.170): icmp_seq=1 ttl=56 time=18.0 ms [...]
Ich erhalte also eine Antwort vom Server.
Das bedeutet,daß der Server über das Netzwerk erreichbar ist. Damit ist die erste Hürde genommen. Ob Du über den Dienst NTP eine Antwort erhälst, ist eine andere Frage. Genau da vermute ich mittlerweile das Problem. Ich habe gerade mal die IP Adresse 213.203.226.170 in Yast eingetragen. Nach einem rcntp force-reloaderhalte cih in /var/log/ntp 15 Jul 22:19:18 ntpd[14981]: ntpd exiting on signal 15 15 Jul 22:22:33 ntpd[15083]: synchronized to LOCAL(0), stratum 10 15 Jul 22:22:33 ntpd[15083]: kernel time sync enabled 0001 15 Jul 22:23:41 ntpd[15083]: synchronized to 213.203.226.170, stratum 2 Funktioniert also. Mir scheint, da ist Dein Weg zu dem NTP Server verstopft. Erzähl mal was über Deine Netzwerkumgebung und Internetverbindung:. - direkte Einwahl von Deinem Rechner über DSL/ISDN/analog Modem? - Internetzugang über DSL Router? - falls "ja": ist eine firewall auf dem Router aktiv? Gibt es Log Einträge auf den Router? - Wenn ich mich recht besinne,hast Du bereits in einer früheren Mail geschrieben, daß die Firewall auf Deinem Client ausgeschaltet ist. Gilt das nach der Neuinstallation noch? - Internet Provider?
Seit 2 Tagen ist aber folgendes-vielleicht hängt das damit zusammen:
Immer, wenn ich den PC längere Zeit nicht betreibe (also nachts oder wenn ich unterwegs bin) drehe ich aus Sicherheitsgründen den Strom komplett ab, damit nichts passiert. War auch bisher kein Problem-seit vorgestern jedoch meldet sich, wenn der PC wieder anfährt, das BIOS mit folgender Meldung:
System configuration data updated ERROR 0271 check date and time settings WARNING 0251 system COMS checksum bad-default configuration used
(Ich hoffe, ich habs richtig abgeschrieben).
Nach dieser Meldung sind alle spezifischen BIOS-Einstellungen (ua. Datum/Zeit) verstellt, welche ich dann manuell wieder einstellen muss. Danach läufts jedoch ganz normal.
In div. Foren führte man diese Meldung auf eine leere BIOS-Batterie zurück. Aber ich habe erst vor ca. 3 Monaten eine ganz neue Batterie eingesetzt-sie kann doch nicht ernsthaft jetzt schon wieder leer sein, oder?
Doch, kann sein. Wenn die Batterie vorher schon zwei Jahre rumlag z.B. Jedenfalls kann das ganz prima erklären warum die Zeit der Hardware-Uhr extrem ungenau läuft und in der Folge auch ntp Probleme bekommt.
Christians frühere Postings verstehe ich so, daß die Systemzeit nach Neustart erst richtig läuft und sich dann verstellt. Das paßt IMHO auf den ersten Bick nicht. Trotzdem vermute ich da irgendwelche nicht erkannte Nebeneffekte.
Ich vermute eher die NTP-Linux-Geschichte dahinter kann mir aber keinen Reim darauf machen.
Glaub' ich weniger. Ich habe noch nie ein nicht absichtlich Schaden verursachendes Programm gesehen dass das CMOS-Setup vermurkst, und ntp macht das in allen Fällen die ich kenne /und das sind einige auf verschiedenster Hardware) auch nicht.
ACK
Viele Grüße und ein schönes HEIßES Wochenende (35 °C-yes:-) )
Mal sehen... zumindest regnet es schon mehrere Stunden lang hier nicht mehr...
0:25, sitze draußen bei angenehmen 24 °C (in D). Morgen soll es schwül werden. Gute Nacht Ralf -- Antworten bitte nur in die Mailingliste! PMs bitte an: listreply (@) arndt-on-line (.) de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Montag, 16. Juli 2007 00:35 schrieb Ralf Arndt: Hallo Ralf, Hallo Arno,
Doch auch explizit. Viele produzieren auf der Liste ungern gesehenen TOFU (Text Oben, Fullquote Unten). Christians mails sind das genaue Gegenteil (Text unten, Full Quote oben) mit dem gleichen Effekt. Man muß durch eine vllt. sehr lange mail scrollen, um zu lesen worauf sich die jeweilige Antwort bezieht. @Christian: Gute Hinweise zum Umgang mit mailinglisten findest Du unter <http://learn.to/quote>
ich versuche mal so zu schreiben, wie ihr es als angenehm empfindet. Jeder hat einen anderen Quote-Stil mit dem er besser klar kommt-ich persönlich finde den oben Originaltext, unten Antwort am Besten, aber ich bin ja flexibel... :-) An Ralf: Danke für deinen Link-Tip-sehr interessant und viele Informationen, die ich mir bei Gelegenheit gerne näher durchlese! Mir scheint, da ist Dein Weg zu dem NTP Server
verstopft. Erzähl mal was über Deine Netzwerkumgebung und Internetverbindung:. - direkte Einwahl von Deinem Rechner über DSL/ISDN/analog Modem? - Internetzugang über DSL Router? - falls "ja": ist eine firewall auf dem Router aktiv? Gibt es Log Einträge auf den Router? - Wenn ich mich recht besinne,hast Du bereits in einer früheren Mail geschrieben, daß die Firewall auf Deinem Client ausgeschaltet ist. Gilt das nach der Neuinstallation noch? - Internet Provider?
Also, dann fang ich mal an:-) Verbindung über DSL mit LAN-Kabel zum Router. Internetzugang erfolgt über DSL-Router (FRITZ!Box Fon WLAN 7141). Firewall ist im Router aktiv, allerdings ist der Port für NTP (UDP 123) von mir freigeschaltet worden. Log-Einträge macht dieses Fritz!Box-Modell leider nicht (hab extra bei AVM geschaut-steht weder im Handbuch, noch in den FAQ's, noch auf der ganzen Seite-Suchfunktion-was davon...) Die Firewall läuft-vielleicht hängt's daran-es sind dort keine Portfreigaben vorhanden...(Schau ich nachher mal genauer hin-vielleicht hat's ja Erfolg...) Internet-Provider ist 1&1 (3DSL).
Christians frühere Postings verstehe ich so, daß die Systemzeit nach Neustart erst richtig läuft und sich dann verstellt. Das paßt IMHO auf den ersten Bick nicht. Trotzdem vermute ich da irgendwelche nicht erkannte Nebeneffekte.
Die Sache mit der BIOS-Batterie hat sich erledigt-siehe hier (http://support.fujitsu-siemens.de/forum/viewtopic.php?t=24882)
0:25, sitze draußen bei angenehmen 24 °C (in D). Morgen soll es schwül werden.
Hier sinds derzeit ca. 35°C (in SP), Sonne, und schwül-kaum auszuhalten hier am Oberrhein...:-) Grüße Christian -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Dienstag, 3. Juli 2007 15:48:02 schrieb Arno Lehmann:
Hallo,
03.07.2007 11:56,, Christian Pubanz wrote:: ...
Hi Arno,
so, nun hab ich eine schöne ntp-start.log, die anbei beiliegt. Leider verstehe ich überhaupt nichts von den geloggten Ereignissen. Anbei außerdem mal mein ntp-Startscript zur Ansicht.
Jetzt hoffe ich, dass du das entschlüsseln kannst und mir sagen kannst, was nun zu tun ist, um diesen Spuk endlich zu beenden. Ich habs langsam satt, meine Uhr ständig mit ntpdate manuell nachzujustieren....:-)
Kann ich verstehen...
Also, ich lasse das Nachjustieren von einem cron-Job machen. Das reicht für meine Ansprüchen an die Genauigkeit der Uhr. Tschö, Emil ... -- Registered Linux User since 19940320 -------------------------------------------------- Emil Stephan, Marktplatz 39, 53773 Hennef, Germany voice: +49-2242-84438 Accelerate Windows: 9.81 m/sec^2 would be adequate -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Mittwoch, 4. Juli 2007 16:09 schrieb Emil Stephan:
Also, ich lasse das Nachjustieren von einem cron-Job machen. Das reicht für meine Ansprüchen an die Genauigkeit der Uhr.
Hi Emil, klar-ich weiß, dass das geht-mir gehts aber um's Prinzip...;-) Trotzdem danke! Grüßle, Christian -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Sonntag, 24. Juni 2007 12:09 schrieb Christian Pubanz:
@Ralf:
Danke für deine Tips, aber ich verstehe dein "Fachchiniesisch" leider nicht. Ich weiß zB. nicht, wie ich "die restrict und die filegen Zeilen auskommentieren" soll. Hab sowas noch nie gemacht und weiß nicht, wie man das macht...
Sorry, ich bin selber nicht gerade ein Experte was Linux betrifft. Ich habe gerade mal meine Mails angesehen und versuche das, was nach Deiner Meinung Fachchinesisch sein könnte aufzulösen (Korrekturen von Besserwissenden sind erwünscht). es gibt zwei Zeiten: 1. Deine Hardware Uhr auch RealTimeClock (RTC) genannt. Das ist eine Batterie gepufferte Uhr in Deinem Rechner, die auch weiterläuft, wenn der Rechner ausgeschaltet ist. Du kannst i.A. die Zeit der RTC auch im BIOS Setup unabhängig von einem Betriebssystemansehen. Die RTC läuft mit einer gewissen Ungenauigkeit. 2. Die Systemzeit: Hier kommt Linux ins Spiel. Linux kann aus zwei Gründen der Meinung sein, daß die Zeit der RTC von der wirklichen Zeit abweicht: 2.1. Gefieferte Uhrzeit von NTP 2.2 Andere Algorithmen die ich auch nicht kenne Insgesamt wird eine drift aus Systemzeit und RTC berechnet. Das ist eine Abweichung zwischen RTC und wirklicher Zeit pro Zeiteinheit (z.B. Pro Tag). Die Systemzeit ist diejenige die verwendet wird (und die Dir angezeigt wird): Diese Zeit wird anhand der angenommenen drift regelmäßig angepaßt. Schicke mal bitte die Ausgabe von cat /etc/adjtime cat /var/lib/ntp/drift
Was Berechtigungen sind, weiß ich zum Glück noch :-) hier sind sie:
/var/lib/ntp/ntp.drift exisitiert;allerdings unter diesem Pfad: /var/lib/ntp/drift
Genau das interssiert mich, Zitat aus Deiner ntp.conf: driftfile /var/lib/ntp/ntp.drift Da weichen existierende Pfade/Dateinemen von Deiner Konfigurations Datei ab.
Datei hänge ich dran, steht aber nicht viel drin..
Berechtigung auf /var/lib/ntp: Einträge anzeigen&Öffnen: Alle Schreiben: Benutzer
Schicke bitte mal die Ausgabe von ll /var/lib/ntp
/var/log/ntpstats/ existiert nicht, also auch keine Berechtigungen.
Noch eine Abweichung, In ntp.conf steht: statsdir /var/log/ntpstats/ Wo kommt eigentlich Deine ntp.conf her? Auf meiner openSUSE 10.2 sieht die Datei ganz anders aus. NTP ist mit Yast konfiguriert, es wurden höchstens NTP Server mit einem Editor hinzugefügt. Deine ntp.conf scheint eine sehr restriktive Datei zur Konfiguration eines NTP Servers zu sein. Optionen wie "kod" finde noch nicht mal in den Beispieldateien. Es ist schon spät also wünsche ich Dir ohne langes redigieren liebe Grüße ERalf -- Antworten bitte nur in die Mailingliste! PMs bitte an: listreply (@) arndt-on-line (.) de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Montag, 11. Juni 2007 22:42 schrieb Christian Pubanz:
addto_syslog: sendto(192.53.103.108) (fd=-1): Bad file descriptor transmit: at 973 192.168.178.21->192.53.103.108 mode 3 addto_syslog: ntpd exiting on signal 2 addto_syslog: can't open /var/lib/ntp/ntp.drift.TEMP: Permission denied ^^^^^^^^^^^^^^^^^^^
Bei mir finde ich eine Datei /var/lib/ntp/drift/ntp.drift ^^^^^ Ob da der Hund begraben ist? Grüße Ralf -- Antworten bitte nur in die Mailingliste! PMs bitte an: listreply (@) arndt-on-line (.) de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Dienstag, 12. Juni 2007 11:49 schrieb Ralf Arndt:
Am Montag, 11. Juni 2007 22:42 schrieb Christian Pubanz:
addto_syslog: sendto(192.53.103.108) (fd=-1): Bad file descriptor transmit: at 973 192.168.178.21->192.53.103.108 mode 3 addto_syslog: ntpd exiting on signal 2 addto_syslog: can't open /var/lib/ntp/ntp.drift.TEMP: Permission denied
^^^^^^^^^^^^^^^^^^^
Bei mir finde ich eine Datei /var/lib/ntp/drift/ntp.drift ^^^^^ Ob da der Hund begraben ist?
Ergänzung: Aus /etc/ntp.conf: ^^ driftfile /var/lib/ntp/drift/ntp.drift # path for drift file Eventuell bearbeitest Du die falsche Konfig? Ralf -- Antworten bitte nur in die Mailingliste! PMs bitte an: listreply (@) arndt-on-line (.) de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Hallo, On 6/12/2007 12:01 PM, Ralf Arndt wrote:
Am Dienstag, 12. Juni 2007 11:49 schrieb Ralf Arndt:
Am Montag, 11. Juni 2007 22:42 schrieb Christian Pubanz:
addto_syslog: sendto(192.53.103.108) (fd=-1): Bad file descriptor transmit: at 973 192.168.178.21->192.53.103.108 mode 3 addto_syslog: ntpd exiting on signal 2 addto_syslog: can't open /var/lib/ntp/ntp.drift.TEMP: Permission denied
^^^^^^^^^^^^^^^^^^^
Bei mir finde ich eine Datei /var/lib/ntp/drift/ntp.drift ^^^^^ Ob da der Hund begraben ist?
Ergänzung: Aus /etc/ntp.conf: ^^ driftfile /var/lib/ntp/drift/ntp.drift # path for drift file
Eventuell bearbeitest Du die falsche Konfig?
Nee, das ist ein Problem des Testlaufs ohne chroot-Umgebung :-) Aber für den Test wollte ich Christian nicht zumuten die manuell vorzubereiten - mir ging's erstmal nur darum zu sehen ob der ntpd dann überhaupt arbeitet. Das tut er. Das Startskript von SuSE ist meiner Meinung nach in Ordnung, ich kenne keine Fälle wo es mit chroot-Umgebung Probleme gemacht hat. Bezüglich der Ursache des nicht-Funktionierens tappe ich im dunkeln, wollen mal sehen was als nächstes rauskommt... ich tippe doch sehr auf ein Konfigurations- oder Netzwerkproblem. Aber das sollte sich entweder per Log der ntpdc-Abfragen eingrenzen lassen. Arno
Ralf
-- IT-Service Lehmann al@its-lehmann.de Arno Lehmann http://www.its-lehmann.de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
Am Dienstag, 12. Juni 2007 12:11 schrieb Arno Lehmann:
Hallo,
On 6/12/2007 12:01 PM, Ralf Arndt wrote:
Am Dienstag, 12. Juni 2007 11:49 schrieb Ralf Arndt:
Am Montag, 11. Juni 2007 22:42 schrieb Christian Pubanz:
addto_syslog: sendto(192.53.103.108) (fd=-1): Bad file descriptor transmit: at 973 192.168.178.21->192.53.103.108 mode 3 addto_syslog: ntpd exiting on signal 2 addto_syslog: can't open /var/lib/ntp/ntp.drift.TEMP: Permission denied
^^^^^^^^^^^^^^^^^^^
Bei mir finde ich eine Datei /var/lib/ntp/drift/ntp.drift ^^^^^ Ob da der Hund begraben ist?
Ergänzung: Aus /etc/ntp.conf: ^^ driftfile /var/lib/ntp/drift/ntp.drift # path for drift file
Eventuell bearbeitest Du die falsche Konfig?
Nee, das ist ein Problem des Testlaufs ohne chroot-Umgebung :-)
Aber für den Test wollte ich Christian nicht zumuten die manuell vorzubereiten - mir ging's erstmal nur darum zu sehen ob der ntpd dann überhaupt arbeitet. Das tut er.
Das Startskript von SuSE ist meiner Meinung nach in Ordnung, ich kenne keine Fälle wo es mit chroot-Umgebung Probleme gemacht hat.
Das trifft nicht ganz das, was ich meine. Mir ist erst jetzt klar geworden, daß _beide_ Dateien: /etc/ntp.conf /etc/sysconfig/ntp benötigt werden. In der ersten Datei steht der Pfad zu /var/lib/ntp/drift/ntp.drift Beachte in der Struktur das Verzeichnis _drift_ (Standard Installation opensuse 10.2). Dieses Zwischenverzeichnis fehlt in der Fehlermeldung des debug Auszugs. /var/lib/ntp/ntp.drift Ob das ganze in einer chroot Umgebung läuft. ist irrelevant, da die komplette Verzeichnisstruktur /var/lib/ntp in das Gefängnis verschoben wird. Ob das jetzt zur Lösung von Christians Problem beiträgt, kann ich nicht sagen. Allerdings sollte man schonmal die Fehlerquelle ausschließen. @Christian: Ohne mich jetzt wirklich mit den Einstellungen in /etc/ntp.conf auszukennen, sieht die Datei erheblich anders aus, als bei mir (Konfiguration über yast). Trotzdem hier ein paar Fragen: Datei /var/lib/ntp/ntp.drift existiert? Berechtigungen auf Verzeichnis /var/lib/ntp? Verzeichnis /var/log/ntpstats/ existiert? Berechtigungen? Was passiert, wenn Du die restrict und die filegen Zeilen auskommentierst? Grüße Ralf -- Antworten bitte nur in die Mailingliste! PMs bitte an: listreply (@) arndt-on-line (.) de -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um eine Liste aller verfuegbaren Kommandos zu bekommen, schicken Sie eine Mail an: opensuse-de+help@opensuse.org
participants (12)
-
Andre Tann -
Arno Jung -
Arno Lehmann -
Christian Pubanz -
Emil Stephan -
gooly＠gmx.at -
Jan Ritzerfeld -
Jan Tiggy -
Martin Schröder -
Michael Schueller -
Ralf Arndt -
Werner Flamme