rpc.statd listend on a random UDP port regardless of startup arguments

[AleksanderAdamowski]

Among other options, I have the following in /etc/defaults/nfs-common:

# Options for rpc.statd.
# Should rpc.statd listen on a specific port? This is especially useful
# when you have a port-based firewall. To use a fixed port, set this
# this variable to a statd argument like: "--port 4000 --outgoing-port 4001".
# For more information, see rpc.statd(8) or http://wiki.debian.org/?SecuringNFS
STATDOPTS="--port 1000 --outgoing-port 999"

When I /etc/init.d/nfs-common restart, arguments get passed to rpc.statd properly:

statd 9964 0.0 0.0 1876 708 ? Ss 12:30 0:00 /sbin/rpc.statd --port 1000 --outgoing-port 999

However, statd still listens on a UDP port that's random (in this case port 812):

t# netstat -anp | grep rpc.statd
tcp 0 0 0.0.0.0:1000 0.0.0.0:* LISTEN 9964/rpc.statd
udp 0 0 0.0.0.0:812 0.0.0.0:* 9964/rpc.statd
udp 0 0 0.0.0.0:1000 0.0.0.0:* 9964/rpc.statd
unix 2 [ ] DGRAM 36015 9964/rpc.statd

Because of this today I had a conflict with CUPS, since statd decided randomly to listen on UDP port 631.

Regardless of that, the defaults are also unacceptable for end user systems, because the NFS daemons randomize their listen poerts and are likely to interfere with CUPS and other services. The Ubuntu default should be statically assigned ports and the daemons should obide by those assignments.

[centyx (centyx-centyx)]

I am also experiencing this issue w/ Hardy i386. I manually run

rpc.statd --port 4000 --outgoing-port 4001

but statd uses a random outgoing port.

ie.

root@support1:~# netstat -anp|grep statd
tcp 0 0 0.0.0.0:4000 0.0.0.0:* LISTEN 30976/rpc.statd
udp 0 0 0.0.0.0:4000 0.0.0.0:* 30976/rpc.statd
udp 0 0 0.0.0.0:624 0.0.0.0:* 30976/rpc.statd

This is not desirable, because I would like to be able to restrict connections to statd on a per host basis in ufw.

[Daniel T Chen (crimsun)]

Is this symptom still reproducible in 8.10 RC or later?

[centyx (centyx-centyx)]

Don't have 8.10 at work, will have to check at home. However, I plan to stay on 8.04 on all of our servers for a good while longer and would really appreciate it being fixed there.
Thanks!

[Waldemar (waldemar-opencodes)]

Will there be any update on this? This is really quite annoying. We have deployed about 300 Ubuntu desktops now, which all work very nicely but now about every week somebody reports that she/he is unable to use any printers because of this bug.

I know you are busy, so will be patient. Just wanted to know whether it is in the pipeline or whether we should consider other possible solutions.

Thanks!

[Xeelee (alex-gaponline)]

Hi,

this bug still appears on nfs-common 1.1.2-4ubuntu1.1 and 1.1.4-1ubuntu1. I tied to install the package for intrepid and jaunty on hardy. But the bug doesn't vanished.

Yours
    Alexander Thomas

[Antonio Batovanja (toni-toni)]

I've stumbled upon this bug as well (Hardy), rpc.statd seems to like port 631...
Some limited testing suggests the option -o (--outgoing--port) is ignored by rpc.statd:

# LANG=en_GB dpkg -l nfs-common
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-f/Unpacked/Failed-cfg/Half-inst/t-aWait/T-pend
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: uppercase=bad)
||/ Name Version Description
+++-==============-==============-============================================
ii nfs-common 1:1.1.2-2ubunt NFS support files common to client and serve

# /sbin/rpc.statd -p 4000 -o 4001
# ps auwwx | grep statd
statd 27434 0.0 0.0 1900 704 ? Ss 14:56 0:00 /sbin/rpc.statd -p 4000 -o 4001
# netstat -upnl | grep statd
udp 0 0 0.0.0.0:898 0.0.0.0:* 27434/rpc.statd
udp 0 0 0.0.0.0:4000 0.0.0.0:* 27434/rpc.statd

[Antonio Batovanja (toni-toni)]

It seems like no-one has reported this bug to the linux-nfs project... I'm doing it now.
I've just tested nfs-utils-1.1.5, this bug has not been fixed. So this bug has to affect jaunty and intrepid as well...

[Steve Langasek (vorlon)]

The original problem that was reported, that statd listens on a random port when -p is passed, is fixed in Ubuntu 9.10.

The linked Debian and upstream bugs appear to refer to a problem regarding the /outbound/ port used; I haven't confirmed whether that issue is present in 9.10, but that's a separate issue.

[Rolf Leggewie (r0lf)]

Hardy has seen the end of its life and is no longer receiving any updates. Marking the Hardy task for this ticket as "Won't Fix".