Date: Fri, 16 Jan 2004 12:38:45 -0500 From: Eric van Gyzen <vangyzen@stat.duke.edu> To: Dan Nelson <dnelson@allantgroup.com> Cc: freebsd-current@freebsd.org Subject: Re: rpc.lockd resource starvation Message-ID: <200401161238.45865.vangyzen@stat.duke.edu> In-Reply-To: <20040115230708.GB53031@dan.emsphone.com> References: <200401151516.03897.vangyzen@stat.duke.edu> <20040115230708.GB53031@dan.emsphone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Dan Nelson wrote: > In the last episode (Jan 15), Eric van Gyzen said: > > I'm running 5.1-RELEASE on my NFS server and my ~50 NFS clients. > > Over a period of a few weeks, the rpc.lockd daemon on the NFS server > > will consume all the privileged udp ports and start using > > high-numbered ports. With no available privileged udp ports, the > > server is unable to mount NFS shares from other machines. (There are > > probably several other unfortunate consequences of which I am not yet > > aware...) Is this behavior expected from rpc.lockd, or might it be a > > bug (or just me breaking my systems again)? > > wow > > I think you just told me why my two busiest NFS servers had to be > rebooted a few months ago (one with 440 days of uptime :( ). Does the > mount fail with "mount: Can't assign requested address"? Yep. > If so, it > also happens on 4.x servers. Currently, they have 214 and 109 open > reserved ports (after 102 and 73 days uptime, respectively), and I'm > betting there are no more than 5 files actually locked on either > system. I wonder if it's just not closing sockets when it's done with > them? Sounds like a reasonable guess to me. I doubt there are more than 424 locked files on my server (the default number of available low-numbered ports). I could be wrong, though...I wonder how I could determine which files it currently holds locked... Eric -- Eric van Gyzen Sr. Systems Programmer http://www.stat.duke.edu/~vangyzen/ ISDS, Duke University
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200401161238.45865.vangyzen>