Hi,
OSG has put together a rpm for testing based on 3.0.3
Doug
On Apr 13, 2011, at 4:08 PM, Patrick McGuigan wrote:
> 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
>>>
|