[jaunty] nfs-common fails to start unless NEED_STATD=no

[Bryce Harrington]

After an upgrade from intrepid to jaunty, I installed nfs-common and attempted to start the nfs-common service.

root@blumonc:/var/log# /etc/init.d/nfs-common start
 * Starting NFS common utilities [fail]

/var/log/daemon.log had this error:

Dec 5 12:53:01 blumonc rpc.statd[10235]: Version 1.1.4 Starting
Dec 5 12:53:01 blumonc sm-notify[10236]: Already notifying clients; Exiting!
Dec 5 12:53:01 blumonc rpc.statd[10235]: unable to register (statd, 1, udp).

After making the following change to /etc/defaults/nfs-common, the nfs-common init script succeeded:

# Do you want to start the statd daemon? It is not needed for NFSv4.
NEED_STATD=no

root@blumonc:/var/log# /etc/init.d/nfs-common start
 * Starting NFS common utilities [ OK ]

[Luis F. Lopez (luis.lopez)]

Confirmed on a brand new Jaunty installation as of 2009-01-02.

Suggested change in /etc/default/nfs-common file solves the issue.

[Noel J. Bergman (noeljb)]

Do you still see this problem after upgrading the kernel to 2.6.28-4?

 $ uname -r
 2.6.28-4-generic

 $ ps auxwww | grep rpc
 statd 3150 0.0 0.0 10300 520 ? Ss Jan02 0:00 /sbin/rpc.statd

and just to confirm that the command in question works:

 # /etc/init.d/nfs-common start
  * Starting NFS common utilities [ OK ]

[Luis F. Lopez (luis.lopez)]

As Noel commented, the issue seems to be fixed by the most recent kernel package:

$ uname -a
Linux 2.6.28-4-server #6-Ubuntu SMP Thu Jan 1 23:42:42 UTC 2009 i686 GNU/Linux

Even when removing the suggested changes to /etc/defaults/nfs-common, the init script starts without problems.

[Matt (meh106)]

I've just upgraded a Hardy machine to Jaunty and experienced this problem. Kernel is 2.6.28-11.

On the machine in question, I'm still using nfs v3, so the NEED_STATD=no workaround did not help.

I think I've solved it by installing the "statd" package and starting that daemon.

Haven't had a chance to use it properly in anger yet though, so can't guarantee that my solution is stable/reliable.

[Noel J. Bergman (noeljb)]

I do not have a statd package installed. Instead:

 # dpkg -S /sbin/rpc.statd
 nfs-common: /sbin/rpc.statd

which is:

  nfs-common 1:1.1.4-1ubuntu1

NFS 3 works fine with Jaunty. At least it has been very stable in transfers for me. I like NFS, preferring it to CIFS. FWIW, with NFSv4, you'll get some odd output, e.g.,

 # ls -l /tmp/ami3
 total 240
 drwxr-xr-x 2 root root 4096 2009-03-11 19:26 bin
 drwxr-xr-x 3 root root 4096 2009-04-19 01:46 boot
 lrwxrwxrwx 1 root root 11 2007-05-23 15:55 cdrom -> media/cdrom

 # ls -l /tmp/ami4
 total 240
 drwxr-xr-x 2 4294967294 4294967294 4096 2009-03-11 19:26 bin
 drwxr-xr-x 3 4294967294 4294967294 4096 2009-04-19 01:46 boot
 lrwxrwxrwx 1 4294967294 4294967294 11 2007-05-23 15:55 cdrom -> media/cdrom

Those are the same file system, one mounted with nfs, the other with nfs4. You can find more (and less) than you want to know by searching Google for NFS4 and 4294967294.

[Antonio J. de Oliveira (ajoliveira)]

Hello

Running Jaunty 64-bit 2.6.28.15 generic, it afects me and is cleared by:

#sudo /etc/init.d/nfs-common restart

Seems some unitialized thing, service was running.

Cheers

Antonio

[mhotze (m-hotze)]

Duplicated the problem and fix described above. It's still there in:

#uname -r
2.6.28.15-generic

NEED_STATD=no in /etc/default/nfs-common solves the issue.

[Steve Langasek (vorlon)]

This is not a kernel problem; the error message indicates that some other statd process is already running that hasn't been properly stopped during upgrade, so starting a second statd process fails.

This bug has been resolved in karmic with the conversion of nfs-common to properly-managed upstart jobs: upstart will act as a process supervisor and ensure there is only one copy of statd running at a time (and fail at the right point if there's a problem trying to stop the old statd on upgrade).

[rajida (daniel-rj-85)]

thank...........