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]