 |
 |
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 >