NTPD hält Bootvorgang auf, wenn WLAN aktiviert ist
Hallo, wenn ich bei meinem Netbook WLAN aktiviere, dann hält NTPD den Bootvorgang solange auf bis ich WLAN deaktiviert habe. Offensichtlich wartet NTPD auf der Schnittstelle ra0 (WLAN) auf ein Signal. Logischerweise ist das gesicherte WLAN-Netz nicht während der Bootzeit verbunden. Die Verbindung zum WLAN-Netz baue ich erst hinterher mit dem NetworkManager auf. Gibt es da ein Workaround, wie ich das umgehen kann? Gruß Sebastian -- Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten Browser-Versionen downloaden: http://www.gmx.net/de/go/browser -- 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
Sebastian Siebert wrote:
Hallo,
wenn ich bei meinem Netbook WLAN aktiviere, dann hält NTPD den Bootvorgang solange auf bis ich WLAN deaktiviert habe.
Offensichtlich wartet NTPD auf der Schnittstelle ra0 (WLAN) auf ein Signal. Logischerweise ist das gesicherte WLAN-Netz nicht während der Bootzeit verbunden. Die Verbindung zum WLAN-Netz baue ich erst hinterher mit dem NetworkManager auf.
Gibt es da ein Workaround, wie ich das umgehen kann?
Du musst die Abhängigkeit mit dem WLAN als Voraussetzung für ntpd einsetzen. Dies geschieht in der Datei /etc/init.d/ntp: ### BEGIN INIT INFO # Provides: ntp ntpd xntpd # Required-Start: $remote_fs $syslog $named # Required-Stop: $remote_fs $syslog # Default-Start: 2 3 5 # Default-Stop: 0 1 6 # Description: Start network time protocol daemon (NTPD). ### END INIT INFO Der Parameter "Required-Start" muss dann durch den Dienst ergänzt werden, der die WLAN-Karte startet. Danach den Dienst noch einmal mit chkconfig deaktivieren und wieder hereinnehmen. Welcher Dienst das bei dir ist, kann ich leider nicht sagen, mit WLAN habe ich zum Glück nichts zu tun. (^-^) Du kannst versuchen, es mit "network" zu ergänzen. Vielleicht reicht das schon. -- Sandy Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com -- 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
On Tue, 28 Oct 2008 17:08:59 +0100, you wrote:
Du kannst versuchen, es mit "network" zu ergänzen. Vielleicht reicht das schon.
Wohl kaum, denn remote_fs setzt network voraus. Philipp -- 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
Philipp Thomas schrieb:
On Tue, 28 Oct 2008 17:08:59 +0100, you wrote:
Du kannst versuchen, es mit "network" zu ergänzen. Vielleicht reicht das schon.
Wohl kaum, denn remote_fs setzt network voraus.
Philipp
Hi, da muss ich Philipp Recht geben. Das Netzwerk wird *bereits* vor NTPD gestartet und ist aus technischer Sicht auch korrekt. Das Bootlog bestätigt diese Reihenfolge auch. Die Frage ist nur, wie kann ich NTPD dazu bringen, dass der Dämon *noch* nicht auf ra0 hören soll, weil er (wie schon erwähnt) auf die besagte WLAN-Schnittstelle zugreift und somit den Bootvorgang blockiert. Hier mal ein Auszug vor der Initialisierung der WLAN-Verbindung, hierbei bleibt NTPD hängen: # ifconfig eth0 Link encap:Ethernet HWaddr 00:21:85:55:62:9C UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:3934843404 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Interrupt:220 Base address:0x2000 lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) ra0 Link encap:Ethernet HWaddr 00:22:43:46:3B:53 UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:412 errors:0 dropped:0 overruns:0 frame:0 TX packets:372 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:40150 (39.2 Kb) TX bytes:0 (0.0 b) Interrupt:17 Auffällig ist in der Logdatei "Message": RX DESC f6c7600 size = 2048 <-- RTMPAllocTxRxRingMemory, Status=0 I/F(ra0) Key1Str Is Invalid key length! Keylen = 0! I/F(ra0) Key2Str Is Invalid key length! Keylen = 0! I/F(ra0) Key3Str Is Invalid key length! Keylen = 0! I/F(ra0) Key4Str Is Invalid key length! Keylen = 0! 1. Phy Mode = 9 2. Phy Mode = 9 RTMPSetPhyMode: channel is out of range, use first channel=1 3. Phy Mode = 9 MCS Set = ff ff 00 00 01 <==== RTMPInitialize, Status=0 0x1300 = 00064300 NET: Registered protocol family 17 warning: `ntpd' uses deprecated v2 capabilities in a way that may be insecure. ===>rt_ioctl_giwscan. 3(3) BSS returned, data->length = 396 ===>rt_ioctl_giwscan. 3(3) BSS returned, data->length = 396 ===>rt_ioctl_giwscan. 2(2) BSS returned, data->length = 269 ===>rt_ioctl_giwscan. 2(2) BSS returned, data->length = 269 usw. usf. (die letzte Zeile wiederholt sich immer wieder) Anscheinend bekommt er die Aufgabe nach einem freien Netzwerk zu suchen, was eigentlich ziemlich unlogisch ist. Denoch bin ich mir bei dieser Schlussfolgerung nicht sicher. Der Verbindungsaufbau zum Router kommt erst zustande, nachdem der KDE Window Manager mit dem NetworkManager geladen ist. Hier ein Auszug: # ifconfig eth0 Link encap:Ethernet Hardware Adresse 00:21:85:55:62:9C UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:917565451 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 Sendewarteschlangenlänge:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Interrupt:220 Basisadresse:0xe000 lo Link encap:Lokale Schleife inet Adresse:127.0.0.1 Maske:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:42 errors:0 dropped:0 overruns:0 frame:0 TX packets:42 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 Sendewarteschlangenlänge:0 RX bytes:2708 (2.6 Kb) TX bytes:2708 (2.6 Kb) ra0 Link encap:Ethernet Hardware Adresse 00:22:43:46:3B:53 inet Adresse:192.168.1.3 Bcast:192.168.1.255 Maske:255.255.255.0 UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:743 errors:0 dropped:0 overruns:0 frame:0 TX packets:201 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 Sendewarteschlangenlänge:1000 RX bytes:81943 (80.0 Kb) TX bytes:5533 (5.4 Kb) Interrupt:17 Dann eigentlich sollte der NTPD Dämon aktiv werden. Gruß Sebastian -- 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
Sebastian Siebert wrote:
Philipp Thomas schrieb:
On Tue, 28 Oct 2008 17:08:59 +0100, you wrote:
Du kannst versuchen, es mit "network" zu ergänzen. Vielleicht reicht das schon. Wohl kaum, denn remote_fs setzt network voraus.
Philipp
Hi,
da muss ich Philipp Recht geben. Das Netzwerk wird *bereits* vor NTPD gestartet und ist aus technischer Sicht auch korrekt. Das Bootlog bestätigt diese Reihenfolge auch.
Die Frage ist nur, wie kann ich NTPD dazu bringen, dass der Dämon *noch* nicht auf ra0 hören soll, weil er (wie schon erwähnt) auf die besagte WLAN-Schnittstelle zugreift und somit den Bootvorgang blockiert.
Irgendwo ist da noch ein Haken in der Logic. WARUM blockiert denn ntpd das WLAN, wenn das WLAN schon aktiv ist? Für mich hört sich das eher so an, als ob das WLAN eben noch nicht aktiv ist, aber ntpd trotzdem versucht, darüber eine Abfrage zu machen, und bis zum Timeout alles blockiert. Ich sehe nur zwei Möglichkeiten: - setze ntpd nicht als Dienst fest, der direkt gestartet werden soll - baue eine Schleife, welche immer wieder den Status von deiner WLAN-Schnittstelle abfragt und erst dann den ntpd startet - erstelle einen Dummyservice, der nichts anderes macht, als den Status der WLAN-Schnittstelle zu prüfen und setze eine Abhängigkeit beim ntpd auf diesen Dummyservice Wozu brauchst du eigentlich ntpd auf einem Desktop? -- Sandy Antworten bitte nur in die Mailingliste! PMs bitte an: news-reply2 (@) japantest (.) homelinux (.) com -- 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 Sandy, ich habe von einem User den Tipp bekommen ntpdate aus dem Startskript von NTP zu deaktivieren. In dem man die Variable NTPDATE_BIN komplett entleert. Nun ja, unter 10.3 existiert eine Abfrage über die Variable. Aber unter 11.0 ist anscheinend das Startskript umgebaut worden und ntpdate wird hier zwar gesetzt, jedoch wird es nicht ausgeführt bzw. ausgewertet.
Irgendwo ist da noch ein Haken in der Logic. WARUM blockiert denn ntpd das WLAN, wenn das WLAN schon aktiv ist? Für mich hört sich das eher so an, als ob das WLAN eben noch nicht aktiv ist, aber ntpd trotzdem versucht, darüber eine Abfrage zu machen, und bis zum Timeout alles blockiert.
Testweise habe ich nochmal WLAN komplett deaktiviert. Nun fährt er merkwürdigerweise hoch, ohne sich an der WLAN-Schnittstelle zu stören. Dabei habe ich doch gar nicht mehr rumgefummelt?! Man müsste bedenken, dass der Mini auf der Arbeit nicht hochfahren wollte und zu Hause fährt er ohne Mucken hoch.
Ich sehe nur zwei Möglichkeiten: - setze ntpd nicht als Dienst fest, der direkt gestartet werden soll - baue eine Schleife, welche immer wieder den Status von deiner WLAN-Schnittstelle abfragt und erst dann den ntpd startet
- erstelle einen Dummyservice, der nichts anderes macht, als den Status der WLAN-Schnittstelle zu prüfen und setze eine Abhängigkeit beim ntpd auf diesen Dummyservice
Danke für den Tipp, hat sich offensichtlich erstmal erledigt. Falls es wieder auftreten sollte, werde ich mal deine Tipps versuchen.
Wozu brauchst du eigentlich ntpd auf einem Desktop?
Ich nutze den Mini nicht nur als Desktop. ;-) Wenn man ständig unterwegs ist und ich mal an einem oder anderem Linux-Server ran muss, ist es schön, wenn die Zeit immer korrekt läuft. Da ich einige Skripte auf dem Mini habe, die sich auf die korrekte Uhrzeit verlassen. Ich denke, dass würde deine Frage beantwortet. :-) Gruß Sebastian -- 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 28.10.2008, 16:19 Uhr, schrieb Sebastian Siebert <Freespacer@gmx.de>: Hallo Sebastian
Gibt es da ein Workaround, wie ich das umgehen kann?
Bei mir liegt angehängtes Script unter /etc/ppp/ip-up.d Damit wird die Abfrage der Zeit erst durchgeführt, wenn die Verbindung aufgebaut ist. So hatte ich das auch schon auf den SuSE-Rechnern. Gruß Stefan -- Betriebssystem Debian GNU/Linux 4.0r5 "Etch" + XFCE Opera 9.62 Build 2466 Erstellt mit Operas revolutionärem E-Mail-Modul: http://www.opera.com/mail/ Nie wieder Bill Gates!
participants (5)
-
Heinz-Stefan Neumeyer -
Philipp Thomas -
Sandy Drobic -
Sebastian Siebert -
Sebastian Siebert