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 or view it on GitHub: https://github.com/xrootd/xrootd/issues/975#issuecomment-490252075 ######################################################################## 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