On Sat, Dec 03, 2005 at 04:17:56PM -0500, Jeff Green wrote:
> Port 2049 seems to have been grabbed by some other package (and am unable to 
> pin down which it is). See for example:
> 
> % netstat -ap | grep 2049
> tcp        0      0 *:2049                  *:*                     LISTEN    
>  -                   

This seems to be yet another case of "the portmap paradigm sucks" (it happily
assigns fixed ports to everything without regard for what's supposed to be
there later); I'm a bit unsure why nlockmgr, which usually gets started along
with nfsd, is started in this case, though:

> % rpcinfo -p
>    program vers proto   port
>     100000    2   tcp    111  portmapper
>     100000    2   udp    111  portmapper
>     100021    1   udp   2048  nlockmgr
>     100021    3   udp   2048  nlockmgr
>     100021    4   udp   2048  nlockmgr
>     100021    1   tcp   2049  nlockmgr
>     100021    3   tcp   2049  nlockmgr
>     100021    4   tcp   2049  nlockmgr
>     391002    2   tcp    881  sgi_fam
>     100024    1   udp    888  status
>     100024    1   tcp    891  status

The only possible culprit I could see would be sgi_fam, but I tried
installing fam on a test machine (even though it's outdated now, with inotify
and all), and it made no difference:

dessverre:~# rpcinfo -p
   program vers proto   port
    100000    2   tcp    111  portmapper
    100000    2   udp    111  portmapper
    100024    1   udp  33245  status
    100024    1   tcp  48500  status
    391002    2   tcp    877  sgi_fam

Lots of things might have changed since you filed your bug, though; do you
still see nlockmgr in your rpcinfo output even when nfsd isn't running?

/* Steinar */
-- 
Homepage: http://www.sesse.net/


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Reply via email to