NFS bringt Netzwerk zum Absturz
Hallo Liste, nachdem ich nun die Festplatten an meinem Server getauscht habe und das System auch soweit wieder läuft, kommt das nächste Problem: Bei NFS-Schreib-Zugriffen vom Client auf den Server (und nur in dieser Richtung!) hängt sich das Netzwerk auf. Das Lesen von Verzeichnissen und Kopieren von Dateien vom Server zum Client funktioniert einwandfrei. Auch alle anderen Dienste funktionieren, soweit ich sie bisher getestet habe, einwandfrei bis zum Absturz durch das NFS. Mit "hängt sich das Netzwerk auf" meine ich, daß nach diesem "Absturz" keine Netzwerkdienste mehr funktionieren. Mail, Telnet, NFS, alles innner Grütz´. Als erste und bisher einzige Abhilfe habe ich bisher den Server nach jedem Absturz heruntergefahren und neu gestartet. Im Moment fehlt mir jeglicher Schimmer, wo ich nach dem Fehler suchen soll. Kann mir jemand aufgrund dieser (kurzen) Beschreibung helfen, evtl. auch mit einer vernebelten Glaskugel? Danke und Bye JT P.S.: Sorry, falls meine Mail mehrfach in die Liste kommen, ich kämpfe im Moment gegen meinen MTA (qmail).
Am Dienstag, 7. August 2001 22:32 schrieb Jan Tim Schueszler: [NFS-Problem] Ich habe das Problem jetzt noch einmal nachvollzogen und schildere, was ich getan habe, bis es zum Absturz kommt. Ich habe mich per Telnet vom Client am Server eingeloggt, um diverse Logs mitzuverfolgen. An einer Konsole kopiere ich nun mittels "cp -a /tmp/LFS /ftp/incoming/" ein Verzeichnis vom Client zum Server; das Verzeichnis /ftp inkl aller Unterverzeichnisse wird vom Server per NFS exportiert mit folgender Zeile in /etc/exports: /ftp (rw) jan (rw,no_root_squash) Nach einigen Augenblicken erhalte ich dann in /var/log/messages auf dem Client folgende Meldungen: Aug 7 23:38:09 jan kernel: nfs: server server not responding, still trying Aug 7 23:38:09 jan last message repeated 4 times Aug 7 23:39:58 jan kernel: nfs: task 3793 can't get a request slot Aug 7 23:39:58 jan kernel: nfs: task 3794 can't get a request slot Aug 7 23:39:58 jan kernel: nfs: task 3795 can't get a request slot Aug 7 23:39:58 jan kernel: nfs: task 3796 can't get a request slot Aug 7 23:39:58 jan kernel: nfs: task 3797 can't get a request slot Bis gerade war er bei task 3819 und tut noch immer nichts. Der Vorgang läßt sich auch nicht killen. Alle anderen Konsolen, die per Telnet am Server hängen, sind blockiert, kein Tastendruck ruft eine wie auch immer geartete Reaktion hervor. Am Server selbst kann ich jedoch an der Konsole arbeiten. Also noch einmal die Bitte, wer nimmt mir die (überreifen) Tomaten von den Augen? Danke und Bye JT
Hi Jan Tim. Jan Tim Schueszler schrieb:
Am Dienstag, 7. August 2001 22:32 schrieb Jan Tim Schueszler:
[NFS-Problem]
Ich habe das Problem jetzt noch einmal nachvollzogen und schildere, was ich getan habe, bis es zum Absturz kommt.
Ich habe mich per Telnet vom Client am Server eingeloggt, um diverse Logs mitzuverfolgen. An einer Konsole kopiere ich nun mittels "cp -a /tmp/LFS /ftp/incoming/" ein Verzeichnis vom Client zum Server; das Verzeichnis /ftp inkl aller Unterverzeichnisse wird vom Server per NFS exportiert mit folgender Zeile in /etc/exports:
/ftp (rw) jan (rw,no_root_squash) 1 2 3 1: Hier sollte ein Tab stehen, _kein_ Leerzeichen! 2: Klammer muß _direkt_ der Client-IP folgen; hier darf _nichts_ stehen! 3: Auch innerhalb der Klammer besser keine Leerzeichen.
(Alle Monat´ wieder...) Woher hast Du die Daten in dieser Zeile? Erscheint mir recht verwürfelt! Ist "jan" der Name der Client-Maschine oder Dein Username? Zweimal rw?? Falls "jan" die Client-Maschine ist, wäre IMHO die folgende Zeile richtig: /ftp <TAB> jan(rw,no_root_squash) [Aus meiner Mail vom 29.07.01] NFS war zumindest früher mal _sehr_ pingelig mit der Syntax, und daran hat sich zumindest in Deiner Version nichts geändert. Hintergrund: Die Zeilen in /etc/exports enthalten genau zwei relevante Angaben, nämlich Ressource und Client-Angaben, alles dahinter ist Kommentar; also auch eine mit Space getrennte Klammer mit Optionen. Und ohne weitere Angaben wird die Ressource /ftp nun einmal read-only exportiert. Ansonsten empfehle ich dringend man exports zur Lektüre! Hth, Norbert
On Wed, Aug 08, 2001 at 02:42:32AM +0200, Norbert Kordts wrote:
Am Dienstag, 7. August 2001 22:32 schrieb Jan Tim Schueszler:
/ftp (rw) jan (rw,no_root_squash) 1 2 3 1: Hier sollte ein Tab stehen, _kein_ Leerzeichen!
das ist wohl nicht mehr ganz so krass, schaden kanns nix aber zwingend ist es wohl auch nicht mehr, zumindest auf aktuellen versionen nicht. -- MfG. Falk
Am Mittwoch, 8. August 2001 02:42 schrieb Norbert Kordts:
Jan Tim Schueszler schrieb:
Am Dienstag, 7. August 2001 22:32 schrieb Jan Tim Schueszler:
[NFS-Problem]
/ftp (rw) jan (rw,no_root_squash) 1 2 3 1: Hier sollte ein Tab stehen, _kein_ Leerzeichen!
Sorry, habe ich falsch dargetsellt. In meiner /etx/exports steht dort ein Tab.
2: Klammer muß _direkt_ der Client-IP folgen; hier darf _nichts_ stehen!
Nicht gemäß dem Beispiel von SuSE (Handbuch 7.1, Kapitel 5.6.2)
3: Auch innerhalb der Klammer besser keine Leerzeichen.
(Alle Monat´ wieder...) Woher hast Du die Daten in dieser Zeile?
Die Daten, bzw. das Format habe ich aus dem SuSE-Handbuch. Dort steht als Beispiel: 1 /home sonne (rw) venus (rw) 2 /usr/X11 sonne (ro) venus (ro) 3 /usr/lib/texmf sonne (ro) venus (rw) 4 / erde(ro,root_squash) 5 /home/ftp (ro) 6 # End of exports Mit meiner o.a. Zeile habe ich entsprechend des Beispiels aus dem SuSE-Handbuch folgendes zu erreichen versucht: Auf /ftp haben alle Rechner Lese/Schreibzugriff (analog zu Zeile 5), Rechner jan hat dazu auch alle root-Rechte (analog zu Zeilen 3 und 4).
Erscheint mir recht verwürfelt! Ist "jan" der Name der Client-Maschine oder Dein Username? Zweimal rw?? Falls "jan" die Client-Maschine ist, wäre IMHO die folgende Zeile richtig:
"jan" ist der Name des Clients, richtig.
/ftp <TAB> jan(rw,no_root_squash)
Und wenn alle Rechner Lese-/Schreibzugriff haben sollen, muß (kann?) es dann doch /ftp <TAB> (rw) jan(rw,no_root_squash) lauten, wenn ich das Beispiel aus dem zitierten SuSE-Handbuch recht verstanden habe, oder? Danke und Bye JT
Am Mittwoch, 8. August 2001 09:47 schrieb Jan Tim Schueszler:
Am Mittwoch, 8. August 2001 02:42 schrieb Norbert Kordts:
Jan Tim Schueszler schrieb:
Am Dienstag, 7. August 2001 22:32 schrieb Jan Tim Schueszler:
Die Daten, bzw. das Format habe ich aus dem SuSE-Handbuch. Dort steht als Beispiel:
1 /home sonne (rw) venus (rw) 2 /usr/X11 sonne (ro) venus (ro) 3 /usr/lib/texmf sonne (ro) venus (rw) 4 / erde(ro,root_squash) 5 /home/ftp (ro) 6 # End of exports
Mit meiner o.a. Zeile habe ich entsprechend des Beispiels aus dem SuSE-Handbuch folgendes zu erreichen versucht:
Auf /ftp haben alle Rechner Lese/Schreibzugriff (analog zu Zeile 5), Rechner jan hat dazu auch alle root-Rechte (analog zu Zeilen 3 und 4).
Zeile 3 hat natürlich nichts damit zu tun, ich habe dort ein Backslash gesehen, wo keines ist und damit angenommen, Zeile 4 wäre die Fortsetzung von Zeile 3. Als Ergänzung möchte ich noch anbringen, daß es sich um kein NFS-spezifisches Problem zu handeln scheint. Ich habe auf dem Client den ftpd per inetd aktiviert und vom Server per ncftp eine Verbindung zum Client aufgebaut. Nachdem die ersten Dateien kopiert waren, tauchte das geschilderte Problem wieder auf. Das Problem liegt also mE im Transfer großer Datenmengen vom Client zum Server. Einen Hardwaredefekt seitens des Servers in Form einer defekten NIC kann ich ausschließen, da ich die NIC bereits einmal getauscht habe, wenn auch nur gegen eine NIC des gleiches Modells (Noname mit Realtek RTL 8139B). Das Netzwerk läuft über einen Level-One 5-Port Switch. Aber aufgrund meiner u.a. schnellen Lösung möchte ich auch hier einen Defekt ausschließen. Als schnelle (aber wohl kaum dauerhafte) Behebung des Problems führt /sbin/init.d/network restart idR zum gewünschten Ergebnis eines wieder funktionierenden Netzwerkes. Meine Bitte um Rat und Hilfe an die Gemeinde bleibt also leider noch bestehen. Danke und Bye JT
Am Mittwoch, 8. August 2001 11:46 schrieb Jan Tim Schueszler:
Als Ergänzung möchte ich noch anbringen, daß es sich um kein NFS-spezifisches Problem zu handeln scheint. Ich habe auf dem Client den ftpd per inetd aktiviert und vom Server per ncftp eine Verbindung zum Client aufgebaut. Nachdem die ersten Dateien kopiert waren, tauchte das geschilderte Problem wieder auf.
Es fehlen ein paar essentielle Informationen: 1. Welche SuSE-Version 2. Welche Kernel-Version (wenn 2.2.x, damit hatte ich auch Probleme bis zum Erscheinen des 2.2.19) 3. Welches Filesystem läuft auf der exportierten Partition (die Probleme mit ReiserFS und NFS werden hier ja des öfteren besprochen). -- Machs gut | http://www.iiv.de/schwinde/buerger/tremmel/ | http://www.knightsoft.de Manfred | http://www.knightsoft-net.de
Hi Jan,
From: "Jan Tim Schueszler"
Am Dienstag, 7. August 2001 22:32 schrieb Jan Tim Schueszler:
[NFS-Problem]
Ich habe das Problem jetzt noch einmal nachvollzogen und schildere, was ich getan habe, bis es zum Absturz kommt.
Ich habe mich per Telnet vom Client am Server eingeloggt, um diverse Logs mitzuverfolgen. An einer Konsole kopiere ich nun mittels "cp -a /tmp/LFS /ftp/incoming/" ein Verzeichnis vom Client zum Server; das Verzeichnis /ftp inkl aller Unterverzeichnisse wird vom Server per NFS exportiert mit folgender Zeile in /etc/exports: /ftp (rw) jan (rw,no_root_squash)
Nach einigen Augenblicken erhalte ich dann in /var/log/messages auf dem Client folgende Meldungen:
Aug 7 23:38:09 jan kernel: nfs: server server not responding, still trying Aug 7 23:38:09 jan last message repeated 4 times Aug 7 23:39:58 jan kernel: nfs: task 3793 can't get a request slot Aug 7 23:39:58 jan kernel: nfs: task 3794 can't get a request slot Aug 7 23:39:58 jan kernel: nfs: task 3795 can't get a request slot Aug 7 23:39:58 jan kernel: nfs: task 3796 can't get a request slot Aug 7 23:39:58 jan kernel: nfs: task 3797 can't get a request slot
Bis gerade war er bei task 3819 und tut noch immer nichts. Der Vorgang läßt sich auch nicht killen.
Alle anderen Konsolen, die per Telnet am Server hängen, sind blockiert, kein Tastendruck ruft eine wie auch immer geartete Reaktion hervor. Am Server selbst kann ich jedoch an der Konsole arbeiten.
Also noch einmal die Bitte, wer nimmt mir die (überreifen) Tomaten von den Augen?
wenn ich das richtig sehe machst Du arbeitest Du mit Kernel nfs. Probiere mal den Deamon. Bei Kernel nfs gab's IMHO diese Prob's. Leider weis ich im Moment nicht's genaues, falls mir wo ich das gelesen habe einfaellt, lasse ich Dich's wissen. (Koennte was im Archiv, ct oder ix sein) mit freundlichen Grüßen Jörg Zimmermann ------------------------------------------- .xsiteing agentur für netzkommunikation 42117 wuppertal - friedrich-ebert-str. 141b tel: 0202/3097070 - fax: 0202/3097072
Am Dienstag, 7. August 2001 22:32 schrieb Jan Tim Schueszler: [NFS-Problem] Ich habe das Problem jetzt noch einmal nachvollzogen und schildere, was ich getan habe, bis es zum Absturz kommt. Ich habe mich per Telnet vom Client am Server eingeloggt, um diverse Logs mitzuverfolgen. An einer Konsole kopiere ich nun mittels "cp -a /tmp/LFS /ftp/incoming/" ein Verzeichnis vom Client zum Server; das Verzeichnis /ftp inkl aller Unterverzeichnisse wird vom Server per NFS exportiert mit folgender Zeile in /etc/exports: /ftp (rw) jan (rw,no_root_squash) Nach einigen Augenblicken erhalte ich dann in /var/log/messages auf dem Client folgende Meldungen: Aug 7 23:38:09 jan kernel: nfs: server server not responding, still trying Aug 7 23:38:09 jan last message repeated 4 times Aug 7 23:39:58 jan kernel: nfs: task 3793 can't get a request slot Aug 7 23:39:58 jan kernel: nfs: task 3794 can't get a request slot Aug 7 23:39:58 jan kernel: nfs: task 3795 can't get a request slot Aug 7 23:39:58 jan kernel: nfs: task 3796 can't get a request slot Aug 7 23:39:58 jan kernel: nfs: task 3797 can't get a request slot Bis gerade war er bei task 3819 und tut noch immer nichts. Der Vorgang läßt sich auch nicht killen. Alle anderen Konsolen, die per Telnet am Server hängen, sind blockiert, kein Tastendruck ruft eine wie auch immer geartete Reaktion hervor. Am Server selbst kann ich jedoch an der Konsole arbeiten. ... [Minuten später] So, die Mail noch einmal bearbeitet, denn es hat sich was getan. Am Server habe ich das Netzwerk einmal neu gestartet, und nach einigen Augenblicken waren sämtliche Konsolen, die am Server gearbeitet haben, wieder frei, noch am Server eingeloggt. Der Kopiervorgang am Client war abgebrochen (oder was auch immer?), und der syslog hat folgende Meldung am Client ausgeworfen: Aug 7 23:59:46 jan kernel: nfs: server server OK Aug 7 23:59:46 jan last message repeated 31 times Das sagt mir aber noch immer nicht viel. Also noch einmal die Bitte, wer nimmt mir die (überreifen) Tomaten von den Augen? Danke und Bye JT
participants (5)
-
Falk Sauer -
Jan Tim Schueszler -
Jörg Zimmermann -
Manfred Tremmel -
Norbert Kordts