rpc.statd

[guennid]

Seit einiger Zeit kann ich nfs nicht mehr richtig benutzen. Wenn ich als user versuche von R1 aus per nfs ein Verzeichnis auf R2 zu mounten, kriege ich diese Fehlermeldung:

Code: Alles auswählen

 rpc.statd is not running but is required for remote locking

Gebe ich als root

Code: Alles auswählen

rpc.statd start

ein, kann der user wieder mounten. Abgesehen davon, dass ich keinen Schimmer davon habe, was rpc.statd ist: Was könnte ich ich da angestellt haben? Wie behebe ich das Problem dauerhaft?

Grüße, Günther

[SubOptimal]

Hi,

rpc.statd kümmert sich, in Bezug auf das Datei-Locking für NFS, um Reboot-Mitteilungen von anderen Rechnern und verwaltet eine Liste von Rechnern, die informiert werden müssen wenn das lokale System neu gestartet wird. Ausführlicheres gibt es mit

Code: Alles auswählen

man rpc.statd

Zur Ursachenforschung:
Gibt es vielleicht Hinweise in den Logdateien?

Code: Alles auswählen

# root Passwort wird abgefragt
su -c "grep statd /var/log/deamon /var/log/syslog"

Was liefert folgendes Kommonado?

Code: Alles auswählen

grep NEED_STATD /etc/default/nfs-common

Irgendwo da würde ich die Ursache vermuten.

SubOptimal

[guennid]

Code: Alles auswählen

 su -c "grep statd /var/log/daemon /var/log/syslog"
Passwort: 
grep: /var/log/daemon: Datei oder Verzeichnis nicht gefunden
/var/log/syslog:Aug  7 07:02:59 buch3 rpc.statd[3767]: Version 1.1.2 Starting

Code: Alles auswählen

~$ grep NEED_STATD /etc/default/nfs-common
NEED_STATD=

Ich kann damit wenig anfangen.

Ist das Problem nicht einfach nur, dass rpc.statd nicht beim Booten (wie vor dem Auftauchen des Phänomens?) startet? Wenn ich's händisch nachhole, ist ja alles in Ordnung.

Grüße, Günther

[SubOptimal]

Hi,

Code: Alles auswählen

 su -c "grep statd /var/log/daemon /var/log/syslog"
Passwort: 
grep: /var/log/daemon: Datei oder Verzeichnis nicht gefunden
/var/log/syslog:Aug  7 07:02:59 buch3 rpc.statd[3767]: Version 1.1.2 Starting

/var/log/daemon: War mein Fehler. Die Datei heisst /var/log/daemon.log.
/var/log/syslog: War das ein manuelles starten oder beim Systemstart?

Code: Alles auswählen

~$ grep NEED_STATD /etc/default/nfs-common
NEED_STATD=

Ok. Das ist also noch auf der Standardeinstellung.

Ist das Problem nicht einfach nur, dass rpc.statd nicht beim Booten (wie vor dem Auftauchen des Phänomens?) startet?

Ja. Und die Ursache wolltest Du doch herausfinden? In den Logdateien hatte ich vermutet eine Fehlermeldung zu finden warum es das nicht tut.

Vielleicht fehlt auch einfach nur das Startskript.

Code: Alles auswählen

ls -l /etc/rc2.d/*nfs*

# sollte folgende Ausgabezeile liefern, die wie angegeben ended
# unter Lenny
/etc/rc2.d/S20nfs-common -> ../init.d/nfs-common
# unter Squeeze
/etc/rc2.d/S18nfs-common -> ../init.d/nfs-common

Startet der Daemon auch, wenn Du, als root, ihn so versuchst zu starten? Wenn nicht, was für Ausgaben hast Du auf der Konsole und/oder obigen Logdateien?

Code: Alles auswählen

/etc/init.d/nfs-common start

SubOptimal

[guennid]

Danke sehr!

An /etc/rc2d hatte ich auch schon gedacht, ich habe aber so gut wie keine Ahnung von der Systematik. Das einzige, was ich mit diesem Verzeichnis bisher zut un hatte, waren Änderungen bei der Numerierung, wenn ein Dienst zu spät gestartet wurde.

Statt

/etc/rc2.d/S20nfs-common -> ../init.d/nfs-common

stand bei mir drin:

/etc/rc2.d/K00nfs-common -> ../init.d/nfs-common

Aus dem K00 habe ich jetzt wieder, wie in README angegeben, ein S20 gemacht und alles ist paletti.

Was mich irritiert: unter rc2d liegen doch lediglich links. Wieso ändert die Namensgebung das Verhalten von /etc/init.d/nfs-common, worauf der link doch schließlich zeigt?

Wie kann diese Änderung zustande gekommen sein?

Grüße, Günther

Grüße Günther

[SubOptimal]

Hi,

Aus dem K00 habe ich jetzt wieder, wie in README angegeben, ein S20 gemacht und alles ist paletti.

Was mich irritiert: unter rc2d liegen doch lediglich links. Wieso ändert die Namensgebung das Verhalten von /etc/init.d/nfs-common, worauf der link doch schließlich zeigt?

In kurz:
- Links die mit einem S starten, starten einen Dienst
- Links die mit einem K starten, stoppen einen Dienst
- die Zahl hinter dem Buchstaben gibt die Reihenfolge an, in der die Dienste gestartet oder gestoppt werden sollen
- die Namen werden vom init Prozess auswertet und die Skripte unter /etc/init.d mit dem entsprechenden Parameter, der dann das Verhalten steuert, gestartet

In lang:
http://www.debian.org/doc/debian-policy ... s-sysvinit

Wie kann diese Änerung zustande gekommen sein?

Kann man so im Nachhinein schlecht beantworten. Hast Du vielleicht mal etwas mit update-rc.d ausprobiert?

SubOptimal

[guennid]

Hast Du vielleicht mal etwas mit update-rc.d ausprobiert?

Eher nicht. Ich habe wicd ab und an mal wegen seiner putzig-nervösen Erscheinungsformen removed. Z.Z. wird die Anbindung ans häusliche lan mit diesem Teil manuell gestartet (Schleppi).