 |
 |
Hi Andrew, This was a test release that I was using for the time being because of the ease of install via RPM. I will revert to the 3.0.2 release for our production, or use the tgz releases for now. Thanks for the detail on this. I was trying to run the latest&greatest available without checking out from git/compiling myself. Clearly if I'm going to be reporting bugs on the code I ought to at least run a more recently snapshot. Cheers, -Aaron On Apr 13, 2011, at 3:57 PM, Andrew Hanushevsky wrote: > Hi Aaron, > > Yes, I would like to know how the 3.0.3-pre8 got into your setup. The 3.0.2 release should not have had an FD leak, every tag between that and the official 3.0.3 tag had the FD leak. So, 3.0.3 does not have this problem. > > Andy > > -----Original Message----- From: Wilko Kroeger > Sent: Wednesday, April 13, 2011 1:47 PM > To: Aaron van Meerten > Cc: xrootd-l > Subject: Re: leaking file handles > > > Hello Aaron > > I am not sure to which git commit version 3.0.3-pre8 corresponds to but it > looks like this version was created before March 7. I suspect the leak you > see is the one that has been fixed in commit adc3302a569 on March 24th and > will be part of the 3.0.3 release. > > Cheers, > Wilko > > > On Wed, 13 Apr 2011, Aaron van Meerten wrote: > >> Hi xrootd list, >> >> I'm running xrootd 3.0.3-pre8 from http://newman.ultralight.org/repos/xrootd/x86_64/ at MWT2. >> >> I've recently begun setting up xrootd on our Tier3 cluster, and I've noticed an interesting problem. Each file I transfer into the xrootd data servers ends up with an open FD by the xrootd process. This means that eventually even with a ulimit of 32768, we are still running out of available file handles for our process. It seems to me that every file handle that's ever been opened/copies is staying open even after the xrdcp that's transferring the data has finished and exited successfully. lsof on the process confirms that the xrootd process is in fact holding open this many files. This happens on both of the data servers that I'm running, although it doesn't seem to an issue on my redirector (which isn't running a Server-Side Inventory, so it might still happen there if I was running in that mode). >> >> >> My solution so far is to simply restart the xrootd process, which then restarts the timer on this problem. However, that's clearly not an ideal solution for production. >> >> I'm curious if anyone else has experienced this, or if there's a good way to avoid it? >> >> Cheers, >> >> -Aaron van Meerten >> MidWest Tier2