NFS-Problem
Michi Burger
Ich habe jetzt die Pakete mittels pirut nachinstalliert aber beim mounten
meines anderen PCs bekomme ich folgende Fehlermeldung:
[root@localhost nfs]# mount 192.168.100.5:/video5 /media/nfs/ -t nfs
mount.nfs: rpc.statd is not running but is required for remote locking
Either use "-o nolocks" to keep locks local, or start statd.
rpc.statd bringt keine Fehlermeldung beim manuellen Starten, scheint aber
trotzdem nicht zu laufen.
Folgende Meldung bekomme ich wenn ich mit rpc.statd -Fd starte:
12/28/2008 21:41:02 rpc.statd[26127]: Version 1.1.0 Starting
12/28/2008 21:41:02 rpc.statd[26127]: Flags: No-Daemon Log-STDERR
Cannot register service: RPC: Unable to receive; errno = Connection
refused
: unable to register (statd, 1, udp).
Wie kann ich auf meine NFS-Freigabe zugreifen?
Ach ja -o nolocks beim Mounten bringt:
Unsupported nfs mount option: nolocks
Besten Dank für Hilfe
Michi.
Andreas Leitgeb
> [root@localhost nfs]# mount 192.168.100.5:/video5 /media/nfs/ -t nfs
> 12/28/2008 21:41:02 rpc.statd[26127]: Flags: No-Daemon Log-STDERR
> Cannot register service: RPC: Unable to receive; errno = Connection refused
Auf welcher maschine ist der rpc.statd jetzt installiert?
Am laptop und/oder am 192.168.100.5 ?
Deiner Beschreibung nach haette ich angenommen auf dem lappi,
aber sinnvoll erschiene es mir eher am nfs-server...
Vielleicht braucht man den auch auf beiden seiten - ich weiss es
selber nicht so genau... aber gelegentlich trifft ja auch ein
Schuss ins blaue :-)
Vielleicht bedarf es auch nur eines portmapper-restarts:
/etc/init.d/portmap restart
Christoph 'Mehdorn' Weber
* Michi Burger <bur...@a1.net>:
> 12/28/2008 21:41:02 rpc.statd[26127]: Version 1.1.0 Starting
> 12/28/2008 21:41:02 rpc.statd[26127]: Flags: No-Daemon Log-STDERR
> Cannot register service: RPC: Unable to receive; errno =
> Connection refused : unable to register (statd, 1, udp).
Läuft auf den Hosts Portmap? Wenn ja, ist er an ein spezielles
Interface gebunden oder nicht?
Das würde zumindest schon einmal erklären, warum sich
statd nicht registrieren kann. Du kannst auch mal mit
'rpcinfo -p "host"' nachgucken, welche Dienste so
registiert sind. Bei meinem Server tauchen da "portmapper",
"nfs", "nlockmgr", "status" und "mountd" auf, bei Clients
findet man in der Liste nur "portmapper", "nlockmgr" und
"status".
Ein lockd wird bei mir nicht explizit gestartet, da neuere
Kernel (2.4.x/2.6.x) das typischerweise selbst übernehmen --
zumindest, wenn er einkompiliert ist.
Christoph
--
*D*amen*o*ber*b*ekleidung, vgl. dazu auch DUB. --
Das nennt man auch "Herrenspielwarenabteilung".
(Ralph Mothes, Roger Schwentker)
Christoph 'Mehdorn' Weber
Da das Thema des Threads so schön paßt: Ich habe auch ein
NFS-Problem. Ich bilde mir ein, es ist überneulich bei einem
Sicherheitsupgrade aufgetreten auf meinem Debian stable. Ist
auch nicht besonders schlimm.
Beim Shutdown versucht das System irgendwann die NFS-Shares
zu umounten ("Unmounting remote and non-toplevel virtual
filesystems"). Dabei hängt das System einiger Zeit dann für
geschätzt eine Minute, bevor es dann weitergeht (Timeout?).
Vor zwei Tagen hatte ich die Idee, doch vor dem Shutdown
mal ein "umount -at nfs" einzugeben, was auch glatt und ohne
erkennbare Verzögerung durchlief. Danach waren alle Shares
ausgehängt. Der Reboot lief dann flott durch. Insofern bin
ich inzwischen recht sicher, daß es ein NFS-Problem ist.
Nur: Was nun? Hatte das selbst schon jemand und weiß eine
Gegenmaßnahme?
(Im Init-Script umountnfs.sh werden die Shares einzeln mit
'umount "mountpoint"' entfernt statt mit 'umount -at nfs',
aber das scheint mir die Wartezeit nicht zu erklären.)
Ansonsten habe ich erst einmal ein strace vor den umount-Aufruf
geschrieben. Vielleicht sehe ich beim nächsten Shutdown dann mehr.
Christoph
--
Wer schonmal versucht hat, nVidia Chips low level
anzusprechen, wird den Gedanken an Voodoo nicht mehr
los. Meist aber in Form von Puppen der Entwickler.
(Lutz Donnerhacke)
Michi Burger
> Auf welcher maschine ist der rpc.statd jetzt installiert? Am laptop
> und/oder am 192.168.100.5 ? Deiner Beschreibung nach haette ich
> angenommen auf dem lappi, aber sinnvoll erschiene es mir eher am
> nfs-server...
Am Laptop, ich nehme an auch am 100.5, aber ich möchte ja auch andere
Laufwerke mounten (Externe HD).
Der Fehler muß am LT liegen, das mounten des 100.5 funktioniert mit
anderen Rechnern.
> Vielleicht bedarf es auch nur eines portmapper-restarts:
> /etc/init.d/portmap restart
Da haben wir es.
Portmap existiert nicht auf meinem LT, und ein Paket namens portmap gibt
es (zumindest in der Paketliste) auch nicht.
Für weitere Hilfe dankbar
Michi.
Michi Burger
> Hallo!
>
> Läuft auf den Hosts Portmap? Wenn ja, ist er an ein spezielles
> Interface gebunden oder nicht?
>
Nein, konnte ich nicht finden.
> Du kannst auch mal mit 'rpcinfo -p "host"' nachgucken
[root@localhost init.d]# rpcinfo -p
rpcinfo: can't contact portmapper: RPC: Remote system error - No such
file or directory
Bei:
[root@localhost init.d]# rpcinfo -p localhost
sieht es so aus:
rpcinfo: can't contact portmapper: RPC: Remote system error - Address
family not supported by protocol
Somit scheint es (vorerst) am fehlenden portmapper zu scheitern.
Da es bei meiner linplus Version das portmap-Paket anscheinend nicht gibt,
bin ich nun etwas ratlos.
Für einen Anstoß in die richtige Richtunh dankbar
Michi.
Michi Burger
> Am Mon, 29 Dec 2008 12:59:40 +0100 schrieb Christoph 'Mehdorn' Weber:
>
>> Hallo!
>>
>> Läuft auf den Hosts Portmap? Wenn ja, ist er an ein spezielles
>> Interface gebunden oder nicht?
>>
>>
> Nein, konnte ich nicht finden.
>
Und es gibt ihn doch.
Habe mel im I-Net gesucht (die Seite war das letzte mal als ich suchte
noch nicht da).
Mit dem Befehl:
sudo yum install portmap
sudo /sbin/service rpcbind restart
klappte es, k.A. wieso die Paketverwaltung das Paket nicht gefunden hat.
Dann mußte ich noch beim mounten
-o nfsvers=2
anfügen und nun läuft es.
Jedenfalls vielen Dank für eure Hilfe
Michi.
Christoph 'Mehdorn' Weber
* Christoph 'Mehdorn' Weber <spam...@das-mehdorn.de>:
> Ansonsten habe ich erst einmal ein strace vor den umount-Aufruf
> geschrieben. Vielleicht sehe ich beim nächsten Shutdown dann mehr.
Es hängt beim umount-Syscall, wenn er mein Home auszuhängen
versucht. Das macht mich allerdings nicht schlauer.
Christoph
--
Die Flut hatte ja schliesslich auch Vorteile: Die Semperoper
wird in die Geschichte eingehen als das einzige Theater, das
ein volles Haus hatte, ohne auch nur eine Vorstellung zu geben.
(Hans-Georg Bickel)
Christoph 'Mehdorn' Weber
* Ralf Döblitz <doeb...@doeblitz.net>:
> Christoph 'Mehdorn' Weber <spam...@das-mehdorn.de> wrote:
>> Es hängt beim umount-Syscall, wenn er mein Home auszuhängen
>> versucht. Das macht mich allerdings nicht schlauer.
> Du hast dich wohl noch nicht ausgeloggt, also ist dein Homedir noch
> aktiv und ein umount ist nicht möglich.
Wenn ich den Aufruf aus dem Init-Script absetze, während mein
Home noch von mir in Benutzung ist, gibt es allerdings keinen
Timeout. Vielmehr kehrt umount sofort mit der Bemerkung zurück,
daß der Mountpoint noch in Benutzung ist und es da nichts dran
ändern wird.
> Wenn man aus einer User-Shell ein reboot absetzt, dann sollte
> man sich bei Home via NFS möglichst schnell ausloggen, damit das
> Homedir freigegeben wird.
Mache ich meist per Ctrl-Alt-Del, wobei ich das in der Inittab
von Reboot auf Halt geändert habe. (Reboot geht trotzdem, wenn
ich nach dem erfolgreichen Halt eben reboote.)
Allerdings ergab sich ein neues Ergebnis: Gestern habe ich
vor dem Ausschalten probehalber mal "umount /home" gesagt --
der Aufruf, der neulich zum Hänger geführt hatte. Ging glatt
durch. Beim Halt blieb das System dann beim Umounten eines
anderen NFS-Shares hängen. Leider hatte ich strace bereits
wieder aus dem Halt-Script entfernt, daher weiß ich nicht,
welches Share es genau war.
Wirkt so, als würde es immer hängen, solange es noch ein
NFS-Share gibt. Aber diese Theorie ist noch zu bestätigen
oder zu widerlegen.
Christoph
--
[Mouse problems]
So, delete /bin/cat --
I tried that. I had to "rm /bin/cat" nine times before it disappeared.
(Gabor Lenart, Mans Rullgard)
Andreas Leitgeb
> Allerdings ergab sich ein neues Ergebnis: Gestern habe ich
> vor dem Ausschalten probehalber mal "umount /home" gesagt --
> der Aufruf, der neulich zum Hänger geführt hatte. Ging glatt
> durch. Beim Halt blieb das System dann beim Umounten eines
> anderen NFS-Shares hängen.
Kann es sein, dass der portmap (oder ein dahinterliegender
dienst) irgendwie *vor* dem umount beendet wird?
Wieder nur ins Blaue geraten.
Christoph 'Mehdorn' Weber
* Andreas Leitgeb <a...@gamma.logic.tuwien.ac.at>:
> Kann es sein, dass der portmap (oder ein dahinterliegender
> dienst) irgendwie *vor* dem umount beendet wird?
Den Verdacht hatte ich auch schon. Da ich immer nur an
Wochenenden am betroffenen Rechner bin, und den nicht
dauernd rebooten will, testet es sich derzeit aber etwas
langsam.
Allerdings wird laut rc-Scripts postmap sogar explizit
vor dem Umount noch einmal gestartet, falls er nicht eh
schon läuft. Ein probeweises Umsortieren der Scripte hat
letzte Woche auch nicht geholfen.
Nun habe ich mal eine Kopie vom NFS-Umounter als S01
einsortiert. Mal schauen.
Christoph
--
Vor einigen Jahren wurde die Deutsche Bundespost aufgeloest und
durch die populaere Post-Lotto-AG ersetzt. Ob und wessen Post Du
erhaeltst, entscheidet sich bei der allmorgendlichen Ziehung in
den Hauptpostaemtern. (Mirko Liss)
Christoph 'Mehdorn' Weber
* Christoph 'Mehdorn' Weber <spam...@das-mehdorn.de>:
> Nun habe ich mal eine Kopie vom NFS-Umounter als S01
> einsortiert. Mal schauen.
Hatte geholfen -- warum auch immer. Aber mit dem Upgrade auf
Lenny hat sich das wieder erledigt.
Christoph
--
Naja, obwohl, auf der Columbia war eine Linux-Kiste, die
dann verglueht ist. Das find ich irgendwie traurig. --
Nun, traurig finde ich, dass es keine FreeBSD Kiste war.
(Andreas Krennmair, Martin Piskernig)
Christoph 'Mehdorn' Weber
* Christoph 'Mehdorn' Weber <spam...@das-mehdorn.de>:
> Hatte geholfen -- warum auch immer. Aber mit dem Upgrade auf
> Lenny hat sich das wieder erledigt.
Interessant. Nachdem das bisherige Board im Rechner den Geist
aufgegeben hatte, habe ich ein anderes Board eingebaut und --
oh Wunder -- meine NFS-Problem sind offenbar gelï¿œst.
Christoph
--
Allerdings werden manche Texte erst beim Uebersetzen wirklich richtig
schlecht: "..., deshalb muessen wir beachten, dass hier kein
Laufzeit-Wasserkopf, sondern ein Weltraum-Wasserkopf vorliegt."
(Hannes Petersen)