All the time I start paldo, I see that the nfs/statd service fails to start so I decided to see how the nfs starts

Now I took a look at the initscript and /lib/lsb/init-functions and it all seems fine, the problem is that nfs.statd binary is not working, it creates the pid file on /var/run but with an empty line. This all means that nfs is not working.

The GDB says that rpc.statd:

"Program exited with code 01."

(The debug is disabled on paldo so no backtrace available)

So here is the output of the daemon.log:

May 26 03:18:03 hp-laptop rpc.statd[2700]: Version 1.2.2 starting
May 26 03:18:03 hp-laptop sm-notify[2701]: Version 1.2.2 starting
May 26 03:18:03 hp-laptop sm-notify[2701]: Already notifying clients; Exiting!
May 26 03:18:03 hp-laptop rpc.statd[2700]: Running as root. chown /var/lib/nfs to choose different user
May 26 03:18:03 hp-laptop rpc.statd[2700]: failed to create RPC listeners, exiting

So the problem is that it failed to create the listeners, and it seems that the problem relies on portmap (some people having this problem said it worked when moving to rpcbind)

I don't use nfs but I saw the problem so I'm repporting, if anyone knows more ...
 
..............................
OSs: Paldo-testing x86_64 :: HP Pavilion dv9680ez

Here is the complete output of the Foreground run with debug level:


[paldo@hp-laptop:/usr/bin]$ sudo rpc.statd -Fd
rpc.statd: Version 1.2.2 starting
rpc.statd: Flags: No-Daemon Log-STDERR TI-RPC
sm-notify: Version 1.2.2 starting
sm-notify: Already notifying clients; Exiting!
rpc.statd: Local NSM state number: 3
rpc.statd: Failed to open /proc/sys/fs/nfs/nsm_local_state: No such file or directory
rpc.statd: Failed to unregister program 100024, version 1
rpc.statd: Effective UID, GID: 29, 29
rpc.statd: Failed to register (statd, 1, udp)
rpc.statd: Failed to register (statd, 1, tcp)
rpc.statd: Unrecognized bind address family: inet6
rpc.statd: Unrecognized bind address family: inet6
rpc.statd: failed to create RPC listeners, exiting

Conclusions?

 
..............................
OSs: Paldo-testing x86_64 :: HP Pavilion dv9680ez

Zitat

rpc.statd: Failed to open /proc/sys/fs/nfs/nsm_local_state: No such file or directory

Maybe a upstream bug of nfs?

Hi Michael,

After a long time I found out that this problem you're point is mainly because of the module nfs not being loaded. But this is still not the main problem.

Code	[In neuem Fenster öffnen]
rpc.statd: Failed to unregister program 100024, version 1

This is the main problem, rpc.statd is failing to unregister, and also failing to register. I don't think it is a problem on the mainstream

EDIT: This problem seems to be related to portmap. The solution is to either move to rpcbind, instead of portmap, or to see portmap installation:

Taking a look at the portmap installation I see that the paldo installation has no rpc group or rpc user, only rpcuser group which has id 29 and there are people claiming that rpc should use id 111.

Another this is that the bug concerns failure on register of tcp and udp, so it might be something related to that and gentoo use a patch to fix tcpd on portmap: http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-nds/portmap/files/portmap-6.0-tcpd.patch?view=markup

Now another thing is that after googling, some said that this happened on the newer version of rpc, but when downgrading to nfs 1.2.0, everything runs fine.

So there seems to be 3 ways, 1) downgrade nfs to 1.2.0 ; 2) fix portmap 6.0 ; 3) move to rpcbind .

Now here is the status of some distributions:

Ubuntu Lucid --- stayed with nfs 1.2.0 and portmap 6.0, which works
Arch Linux --- have the newest nfs but moved to rpcbind, which also works
Gentoo --- still uses nfs 1.1.4 with portmap 6.0, which is also working
Debian Testing --- uses nfs 1.2.2, but user can choose for portmap or rpcbind, seems to have some bugs when user uses it with portmap
Fedora 13 --- uses nfs 1.2.3-rc3 (but calls it 1.2.2) with rpcbind
OpenSuSE 11.3 --- uses nfs 1.2.1 with rpcbind
Mandriva 2010.1 --- uses nfs 1.2.2 with rpcbind

So as I see, everyone that uses nfs bigger then 1.2.0 has moved to rpcbind. I'll try to install rpcbind (as a move from portmap) on my system, and see if this nfs error disappears. I'll post the report in here
 
..............................
OSs: Paldo-testing x86_64 :: HP Pavilion dv9680ez

FINAL REPORT:

THIS BUG GETS FIXED WHEN MOVING FROM PORTMAP TO RPCBIND

I have moved my system from portmap to rpcbind and now statd works correctly.

Here is the rpcbind spec:

Code	[In neuem Fenster öffnen]
<?xml version="1.0"?> <package name="rpcbind"> <description>portmap replacement which supports RPC over various protocols</description> <releases> <release version="0.2.0" revision="1" branch="testing"> <deps> <dep name="libtirpc"/> </deps> <build> <script> <archive name="$NAME-$VERSION"> <cmd>./configure --bindir=/sbin</cmd> <cmd>make -j 2</cmd> <cmd>make install</cmd> <install name="init-rpcbind-20100806" dest="/etc/init.d/rpcbind" mode="0755"/> </archive> </script> </build> </release> </releases> </package>

And here is the init script (init-rpcbind-20100806)

Code	[In neuem Fenster öffnen]
#!/bin/bash ### BEGIN INIT INFO # Provides: $portmap $rpcbind # Required-Start: $network # Required-Stop: $network # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 ### END INIT INFO . /lib/lsb/init-functions case "$1" in start) echo -n "Starting RPC portmap daemon: rpcbind" start_daemon /sbin/rpcbind log_success_msg "." ;; stop) echo -n "Stopping RPC portmap daemon: rpcbind" killproc /sbin/rpcbind log_success_msg "." ;; restart) $0 stop sleep 1 $0 start ;; *) echo "Usage: $0 {start|stop|restart}" exit 1 ;; esac

After that remove portmap and install rpcbind, and create an transition package for portmap:

Code	[In neuem Fenster öffnen]
<?xml version="1.0"?> <package name="portmap"> <description>rpc portmap daemon</description> <releases> <release version="6.0" revision="2" branch="testing"> <deps> <dep name="rpcbind"/> </deps> </release> </releases> </package>

This should do the trick, restart and you'll see that rpc.statd doesn't fail anymore
 
..............................
OSs: Paldo-testing x86_64 :: HP Pavilion dv9680ez

Great work.
Thank you for your efforts. :-)

Thanks for your work. I've already tried switching to rpcbind in April 2009, however, there were issues with the rpcbind version back then, so I switched back to portmap. As you write that the current rpcbind version is working well, I've committed the changes to again switch to rpcbind.