What Matevz says is completely correct. However, even after exhausting file descriptors, xrootd should neither crash nor give bad data. So, at least for the crash could we get a traceback or (hoping for the impossible) access to the core file.



From: Matevž Tadel
Sent: Tuesday, May 07, 2019 10:29 AM
To: xrootd/xrootd
Cc: Subscribed
Subject: Re: [xrootd/xrootd] Rising number of open files in xcache (#975)

Hi Nikolai,

Actually we just figured this one out with Andy ... this due to relatively short default timeout (180s) given to the cache to close a file after a client disconnect. When a system is busy, cache can not finish writing to the file in time and then xrootd layer decides to "leak" it. We are working on a proper fix but in the meantime, please use:
pss.ciosync 60 900
to increase the time given to the cache to close the file. The above line means try every 60s for a total of 900s -- this works for us at UCSD where we also had this problem.

See:
http://xrootd.org/doc/dev49/pss_config.htm#_Toc525070685

Cheers,
Matevz


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.


You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.

[ { "@context": "http://schema.org", "@type": "EmailMessage", "potentialAction": { "@type": "ViewAction", "target": "https://github.com/xrootd/xrootd/issues/975#issuecomment-490252075", "url": "https://github.com/xrootd/xrootd/issues/975#issuecomment-490252075", "name": "View Issue" }, "description": "View this Issue on GitHub", "publisher": { "@type": "Organization", "name": "GitHub", "url": "https://github.com" } } ]

Use REPLY-ALL to reply to list

To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1