 |
 |
> xrd.tls and xrd.tlsca are treated **identically** to their http counterparts yes, I can confirm that. Yesterday I've reset everything back to `xrd.tls*` without any issues. Our university network team also had a look and identified a common theme: > The resets happen after the redirector sends a FIN to FTS server. I would expect FTS server to stop sending data/request to redirector after that stage but it continues to send requests. redirector resets (RST) any further connection attempt from FTS server after it has sent the FIN. In our logs this looks like ``` # server 220928 14:10:37 5253 XrdLink: Unable to send to 7dc42260.360:[log in to unmask]; connection timed out 220928 14:10:37 5253 XrootdXeq: 7dc42260.360:[log in to unmask] disc 2:31:53 (socket error) # redirector 220928 14:10:53 065 7dc42260.3507:[log in to unmask] Xrootd_Protocol: redirecting to io-37-02.acrc.bris.ac.uk:1194 220928 14:10:53 065 XrootdXeq: 7dc42260.3507:[log in to unmask] disc 0:00:00 (send failure) ``` We've tried to tune TPC with ``` ofs.tpc logok cksum adler32 fcreds ?gsi =X509_USER_PROXY autorm ttl 60 70 xfr 100 pgm /etc/xrootd/xrdcp-tpc.sh ``` but we were told that this has nothing to do with HTTP TPC - so we removed it yesterday. We still get timeouts 80% of the time. I also had a look at `limits.conf` and sysctl settings, but AFAIK there is nothing limiting the connections. Do you have an idea what to check next? -- Reply to this email directly or view it on GitHub: https://github.com/xrootd/xrootd/issues/1736#issuecomment-1262005584 You are receiving this because you commented. Message ID: <[log in to unmask]> ######################################################################## 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