[SOLVED] rpc.statd not running

David the H. · 04-01-2011, 05:38 AM

I ran a large system update yesterday, and after a system reboot (for a new kernel), my nfs shares refused to mount. I keep getting error messages stating that statd isn't running.

Attempting to restart the nfs-common or nfs-kernel-server services results in the same error message.

I tried starting it manually using rpc.statd, and even though I get no errors from it, it doesn't appear to actually launch it.

/var/log/syslog has several entries like this:

Code:

rpc.statd[28523]: Version 1.2.3 starting
sm-notify[28524]: Version 1.2.3 starting
sm-notify[28524]: Already notifying clients; Exiting!

And /var/log/daemon.log has entries like this:

Code:

rpc.mountd[665]: mountd: could not create listeners
rpc.idmapd[671]: main: open(/var/lib/nfs/rpc_pipefs/nfs): No such file or directory
rpc.mountd[706]: mountd: could not create listeners
rpc.statd[722]: Version 1.2.3 starting
sm-notify[723]: Version 1.2.3 starting
sm-notify[723]: Already notifying clients; Exiting!
rpc.statd[722]: failed to create RPC listeners, exiting
rpc.statd[734]: Version 1.2.3 starting
rpc.statd[734]: Flags: TI-RPC
rpc.statd[734]: failed to create RPC listeners, exiting
~~~
rpc.statd[1238]: Caught signal 15, un-registering and exiting
rpc.statd[10105]: Version 1.2.3 starting
sm-notify[10106]: Version 1.2.3 starting
sm-notify[10106]: Already notifying clients; Exiting!
rpc.statd[10105]: Failed to read /var/lib/nfs/state: Success
rpc.statd[10105]: Initializing NSM state
rpc.statd[10105]: failed to create RPC listeners, exiting

I'm not sure what any of these mean.

I've been looking around the web, but I haven't been able to find anything useful, or even understandable to me. Most of what I find are old bugs or dead-end threads. I managed to get my shares to mount by adding the nolock option to the mount commands, but I'm not completely sure what that really does or whether it's safe or not to do so.

Can anyone please help me diagnose and fix this problem?

AlucardZero · 04-01-2011, 08:20 AM

What distro is this? Debian Unstable like your profile says?

Try "mkdir -p /var/lib/nfs/rpc_pipefs" then restarting portmap (or rpcbind), and any/all nfs-* and rpc.* init.d entries.

David the H. · 04-01-2011, 10:55 AM

Thank you. Yes, it's Debian as my profile says.

Still no go. I even tried chmodding the directory to 777 and creating an "nfs" fifo in it manually. statd still fails to start.

I've also played around a bit with /var/lib/nfs/state. It's just a small 4 byte binary file, and if I remove it, it gets recreated.

David the H. · 04-20-2011, 01:09 PM

Just to follow up, I've finally discovered the problem. Portmap appears to be the culprit, and various distros, including mine, are in the process of migrating to rpcbind. But there was also a bug in the debian packaging system keeping it from transitioning properly.

http://www.held.org.il/blog/2010/01/...nd-transition/

I don't know why this affected me now, since this all seems to have been corrected long ago, but manually installing rpcbind and updating to the newest versions of nfs-common and nfs-kernel-sever, then rebooting, seems to have fixed everything. There are a couple of strange error lines when booting up, but they don't appear to be anything serious.

Cheers!

singham · 04-13-2012, 01:37 AM

rpc.statd[10105]: Version 1.2.3 starting
sm-notify[10106]: Version 1.2.3 starting
sm-notify[10106]: Already notifying clients; Exiting!
rpc.statd[10105]: Failed to read /var/lib/nfs/state: Success
rpc.statd[10105]: Initializing NSM state
rpc.statd[10105]: failed to create RPC listeners, exiting
-----------------------------------------------------------------

Tried restarting nfslock but to no avail, then tried with vers=3 option but that also did not worked. Checked the rpcbind/portmap daemon which was not running.So, started it.
# /etc/init.d/rpcbind start
After that started nfslock,
#/etc/init.d/nfslock and tried to remount the nfs share and all went fine.