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]