 |
 |
Hi Patrick, The 3.0.3 tag has been cut and the release is official. Lukasz will be putting it up on the web site during this week or early next. Andy -----Original Message----- From: Patrick McGuigan Sent: Wednesday, April 13, 2011 2:08 PM To: Andrew Hanushevsky Cc: Wilko Kroeger ; Aaron van Meerten ; xrootd-l Subject: Re: leaking file handles Hi Andy, Is there a target date for the release of 3.0.3? --Patrick On 04/13/2011 03: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 >>