(gelöst) Netzwerk in rc.local

[Marcus]

Hi allerseits,

mir ist aufgefallen, dass das Netzwerk während der ausführung der rc.local bei mir teilweise noch nicht verfügbar ist. Ich nutze dhcp zur Konfiguration der Netzwerkkarte. Weiss jemand, ob ich irgendwo einstellen kann, dass er die anderen Services erst starten soll, wenn das Netzwerk wirklich oben ist (evtl. verbunden mit einem timeout)?

Viele Grüsse
Marcus

[syssi]

Ich gehe davon aus, dass auch beim korrekten Einsatz von DHCP die Ordner /etc/network/if-up.d etc. abgearbeitet werden.

[Cae]

Ich gehe davon aus, dass auch beim korrekten Einsatz von DHCP die Ordner /etc/network/if-up.d etc. abgearbeitet werden.

Demnach auch die "(pre|post|)-(up|down)"-Direktiven in /etc/network/interfaces.

Gruß Cae

[rendegast]

dmesg ?
Logs?
-> Dauert das 'Up' der Netzwerkkarte so lange oder der dhcp-Dialog?

Eventuelle Firmware für die Netzwerkkarte ('lspci -nn') vorhanden?

Wie schnell bekommen andere Rechner vom dhcp eine IP?
Reset oder Firmware-Upgrade des Routers/AP? Dessen Logs?

System? Kernel oder Netzwerkmodul selbst gebaut?

[Marcus]

Ok, ich habe in der Zwischenzeit ein bisserl rumprobiert. Zunächst habe ich aus dem rc.local scripten ein 'richtiges' init script gemacht und dort ein: # Required-Start: $remote_fs $network $time $syslog reingesetzt. Laut check-initd-order wird das script auch brav nach dem Netzwerk und remotefs gestartet. Zum Hintergrund: ich möchte in meinem init script auf ein NFS share zugreifen, am besten mit autofs.

Leider ist der Start des netzwerk inits wohl nicht gleichbedeutent mit: Netzwerk wurde auch konfiguriert. So wie es aussieht wird der dhcpclient in den Background geschoben. Ich würde aber gerne erreichen, dass er es ein weilchen wartet und erst dann mit dem Start der weiteren Dienst fortfährt. Laut logs ist gar nicht so viel notwendig. Er versucht halt das NFS Share schon zu mounten, auch wenn er noch gar keine IP hat, was natürlich fehlschlägt.

Hier die relevanten Einträge aus dem syslog:

Code: Alles auswählen

Feb  2 16:23:12 mymachine dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 5
Feb  2 16:23:12 mymachine /usr/sbin/cron[1539]: (CRON) INFO (pidfile fd = 3)
Feb  2 16:23:12 mymachine /usr/sbin/cron[1540]: (CRON) STARTUP (fork ok)
Feb  2 16:23:12 mymachine /usr/sbin/cron[1540]: (CRON) INFO (Running @reboot jobs)
Feb  2 16:23:12 mymachine automount[1512]: create_udp_client: hostname lookup failed: Temporary failure in name resolution
Feb  2 16:23:12 mymachine automount[1512]: create_tcp_client: hostname lookup failed: Temporary failure in name resolution
Feb  2 16:23:12 mymachine automount[1512]: lookup_mount: exports lookup failed for nas.mydomain
Feb  2 16:23:12 mymachine automount[1512]: update_negative_cache: key "nas.mydomain" not found in map.
Feb  2 16:23:13 mymachine dhclient: DHCPOFFER from XXX
Feb  2 16:23:13 mymachine dhclient: DHCPREQUEST on eth0 to 255.255.255.255 port 67
Feb  2 16:23:13 mymachine dhclient: DHCPACK from XXX
Feb  2 16:23:13 mymachine dhclient: bound to YYY

Ich habe zwar in /etc/default/ifupdown den Parameter IFUPDOWN_TIMEOUT=60 gefunden, der scheint aber keine Auswrikung zu haben (steht auch 'currently not used' drüber). Wenn er funktionieren würde, sollte er so wie ich es verstehe zumindestens bei einem NFS Eintrag in der fstab warten, da das mountfs script in /etc/network/if-up.d wohl versucht diesen zu mounten.

Evtl. macht ein kleines Script in /etc/network/if-up.d Sinn, dass prüft ob das device eine IP bekommen hat.

Noch zu deinen weiteren Fragen rendegast: das up geht schnell, der dhcp dialog dauert etwas länger. In diesem Rechner ist eine Intel 82577LM verbaut. Systemmässig ist alles stock squeeze. Bis auf die obigen Meldungen gibt es keine Auffälligkeiten im syslog oder dmesg.

Viele Grüsse
Marcus

[rendegast]

Der dhcp-Dialog dauert nur eine Sekunde.
Und das ist zu lange bis rc.local anläuft?

Dann dürfte doch ein 'sleep 2' in rc.local reichen.

[Marcus]

Hi nochmal,

ist leider etwas komplexer. Obige Meldungen kriege ich nur, wenn ich das Share in die fstab eintrage. Mounten tut er es trotzdem nicht, wie man sieht. Wenn ich das weglasse verhält sich das ganze ziemlich anders. Er scheint das ifup sehr früh in den bg zu schiessen und startet dann einfach weiter. Hier kommt es eigentlich fast immer vor, dass die nachfolgenden Services noch kein Netz haben (egal welche). Der query dauert dann auch deutlich länger. Wenn ich ifup manuell in der Kommandozeile starte dauert es ungefährt 7-8 Sekunden. Da ist ein boot schon fast durch.

Viele Grüsse
Marcus

[Marcus]

http://www.linux-archive.org/debian-use ... -dhcp.html

beschreibt meine Situation recht genau. Leider auch ohne Lösung.

Viele Grüsse
Marcus

[rendegast]

Ich habe mal einen Bootvorgang notiert

Code: Alles auswählen

# egrep -i "dhc|bound" * 

# egrep -i "eth|netw|cron|autofs|automo" * 
boot:Fri Feb  3 09:04:14 2012: Setting up networking....
boot:Fri Feb  3 09:04:15 2012: /etc/init.d/.AUTOFSCK start im LEVEL S
boot:Fri Feb  3 09:04:16 2012: Configuring network interfaces...done.
boot:Fri Feb  3 09:04:26 2012: Starting Ethernet station monitor daemon: (chown arpalert /var/lib/arpalert/arpalert.leases) Feb  3 09:04:26 arpalert: Auto selected device: eth0
boot:Fri Feb  3 09:04:26 2012: Starting Ethernet/FDDI station monitor daemon: (chown arpwatch /var/lib/arpwatch/arp.dat) arpwatch.
boot:Fri Feb  3 09:04:26 2012: Starting automount: done.
boot:Fri Feb  3 09:04:29 2012: Starting advanced periodic command scheduler: fcron.

daemon.log:Feb  3 09:04:26 testing116 arpalert: Auto selected device: eth0
daemon.log:Feb  3 09:04:26 testing116 arpwatch: listening on eth0
daemon.log:Feb  3 09:04:28 testing116 automount[1383]: syntax error in nsswitch config near [ syntax error ]

dmesg:[    1.010873] Initializing network drop monitor service
dmesg:[    1.072596] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
dmesg:[    1.074301] r8169 0000:02:00.0: eth0: RTL8168c/8111c at 0xffffc9000060a000, macmacmac, XID 1c4000c0 IRQ 42
dmesg:[    1.075708] r8169 0000:02:00.0: eth0: jumbo features [frames: 6128 bytes, tx checksumming: ko]
dmesg:[   12.438680] r8169 0000:02:00.0: eth0: link down
dmesg:[   12.440277] r8169 0000:02:00.0: eth0: link down
dmesg:[   14.115679] r8169 0000:02:00.0: eth0: link up

kern.log:Feb  3 09:04:24 testing116 kernel: [    1.010873] Initializing network drop monitor service
kern.log:Feb  3 09:04:24 testing116 kernel: [    1.072596] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
kern.log:Feb  3 09:04:24 testing116 kernel: [    1.074301] r8169 0000:02:00.0: eth0: RTL8168c/8111c at 0xffffc9000060a000, macmacmac, XID 1c4000c0 IRQ 42
kern.log:Feb  3 09:04:24 testing116 kernel: [    1.075708] r8169 0000:02:00.0: eth0: jumbo features [frames: 6128 bytes, tx checksumming: ko]
kern.log:Feb  3 09:04:24 testing116 kernel: [   12.438680] r8169 0000:02:00.0: eth0: link down
kern.log:Feb  3 09:04:24 testing116 kernel: [   12.440277] r8169 0000:02:00.0: eth0: link down
kern.log:Feb  3 09:04:24 testing116 kernel: [   14.115679] r8169 0000:02:00.0: eth0: link up

messages:Feb  3 09:04:24 testing116 kernel: [    1.010873] Initializing network drop monitor service
messages:Feb  3 09:04:24 testing116 kernel: [    1.072596] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
messages:Feb  3 09:04:24 testing116 kernel: [    1.074301] r8169 0000:02:00.0: eth0: RTL8168c/8111c at 0xffffc9000060a000, macmacmac, XID 1c4000c0 IRQ 42
messages:Feb  3 09:04:24 testing116 kernel: [    1.075708] r8169 0000:02:00.0: eth0: jumbo features [frames: 6128 bytes, tx checksumming: ko]
messages:Feb  3 09:04:24 testing116 kernel: [   12.438680] r8169 0000:02:00.0: eth0: link down
messages:Feb  3 09:04:24 testing116 kernel: [   12.440277] r8169 0000:02:00.0: eth0: link down
messages:Feb  3 09:04:24 testing116 kernel: [   14.115679] r8169 0000:02:00.0: eth0: link up

syslog:Feb  3 09:04:24 testing116 kernel: [    1.010873] Initializing network drop monitor service
syslog:Feb  3 09:04:24 testing116 kernel: [    1.072596] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
syslog:Feb  3 09:04:24 testing116 kernel: [    1.074301] r8169 0000:02:00.0: eth0: RTL8168c/8111c at 0xffffc9000060a000, 00:e0:4d:b1:ac:75, XID 1c4000c0 IRQ 42
syslog:Feb  3 09:04:24 testing116 kernel: [    1.075708] r8169 0000:02:00.0: eth0: jumbo features [frames: 6128 bytes, tx checksumming: ko]
syslog:Feb  3 09:04:24 testing116 kernel: [   12.438680] r8169 0000:02:00.0: eth0: link down
syslog:Feb  3 09:04:24 testing116 kernel: [   12.440277] r8169 0000:02:00.0: eth0: link down
syslog:Feb  3 09:04:24 testing116 kernel: [   14.115679] r8169 0000:02:00.0: eth0: link up
syslog:Feb  3 09:04:26 testing116 arpalert: Auto selected device: eth0
syslog:Feb  3 09:04:26 testing116 arpwatch: listening on eth0
syslog:Feb  3 09:04:28 testing116 automount[1383]: syntax error in nsswitch config near [ syntax error ]
syslog:Feb  3 09:04:29 testing116 fcron[1439]: fcron[1439] 3.0.1 started
syslog:Feb  3 09:04:29 testing116 fcron[1439]: updating configuration from /var/spool/fcron
syslog:Feb  3 09:04:29 testing116 fcron[1439]: adding file systab

Ein "dhc" taucht da gar nicht auf, erst später im Betrieb
(bis jetzt 10:13 noch gar nicht).
Die Ausgabe bei Dir muß also nichts heißen,
kann auch vom verwendetet dhcp-Client (dhcpcd?) herrühren.

Code: Alles auswählen

 
# dpkg -l | grep -i dhc
ii  dhcping                                                1.2-4                          DHCP Daemon Ping Program
ii  isc-dhcp-client                                        4.1.1-P1-15+squeeze3           ISC DHCP client
ii  isc-dhcp-common                                        4.1.1-P1-15+squeeze3           common files used by all the isc-dhcp* packages

Andernfalls vielleicht lease-Time des Routers nachsehen?

"boot:Fri Feb 3 09:04:14 2012: Setting up networking...."
kommt von rcS.d/S11ifupdown
"boot:Fri Feb 3 09:04:16 2012: Configuring network interfaces...done."
kommt von rcS.d/S15networking nach dessen 'ifup -a'
Ansonsten rc5.d/S02autofs, rc5.d/S02fcron gleichzeitig mit dem netzwerk-benutzendem S02chrony.



Falls Du init.d/rc.boot aktiviert hast,
könnte auch dort eine Warteschleife bis zur Initialisierung des Interfaces eingelegt werden.
Das sollte aber mit einem timeout geschehen (5s, 10s wären praktikabel?),
da es ja die Komplettierung des Bootvorgangs anhand eines simplen Netzwerkfehlers verhindern könnte.

Wenn ich ifup manuell in der Kommandozeile starte dauert es ungefährt 7-8 Sekunden.

Das erscheint mir nun doch lange für eine eth-IP-Erteilung im Heimnetz.
Dann wäre eine ~ 10s-Schleife doch nur ein walkaround für ein tiefergehendes (router-/switch-)Problem?
Andere Netzwerkkarte ausprobieren?





---------------------------------------------------------

Leider auch ohne Lösung.

Der systematische Ansatz dafür sind ja die event-basierten Bootsysteme.

[Marcus]

So, nach viel Rumsucherei war die Lösung doch viel einfacher als gedacht.

Ich habe die Installation der Maschine mit preseed automatisiert. Während der Installation hat er in die interfaces folgendes geschrieben:

allow-hotplug eth0
iface eth0 inet dhcp

Nachdem ich ein auto eth0 hinzugefügt habe, wird der dhclient auch nicht mehr in den bg geforked sondern läuft brav solange wie seine timeout optionen sind.

Warum genau der auto Eintrag dazu notwendig war, ist mir allerdings nicht klar. Ich habe zu diesem Parameter eher wenig bis keine Doku gefunden.

Vielen Dank und Grüsse aus der Schweiz
Marcus