We run a regular probe to test all EOS instances for monitoring purposes using GSI authentication. When we switch the probe from XRood4 to use the EPEL version XRootd5, we see fluctuating delays of few seconds. The problem shows in the debug log like this: ``` [2023-02-02 15:47:06.253542 +0100][Debug ][XRootDTransport ] [eosalice:1094.0] Logged in, session: bf526b05e8b30000c0060000f77b6b05 [2023-02-02 15:47:06.253552 +0100][Debug ][XRootDTransport ] [eosalice:1094.0] Authentication is required: &P=gsi,v:10600,c:ssl,ca:5168735f.0|4339b4b c.0 [2023-02-02 15:47:06.253568 +0100][Debug ][XRootDTransport ] [eosalice:1094.0] Sending authentication data sec_Client: protocol request for host eosalice token='&P=gsi,v:10600,c:ssl,ca:5168735f.0|4339b4bc.0' sec_PM: Loaded gsi protocol object from libXrdSecgsi.so Secgsi ------------------------------------------------------------------- Secgsi Mode: client Secgsi Debug: 1 Secgsi CA dir: /etc/grid-security/certificates/ Secgsi CA verification level: verifyss Secgsi CRL dir: /etc/grid-security/certificates/ Secgsi CRL extension: .r0 Secgsi CRL check level: try Secgsi CRL refresh time: 86400 Secgsi Certificate: /root/.globus/usercert.pem Secgsi Key: /root/.globus/userkey.pem Secgsi Proxy file: /tmp/x509up_u0 Secgsi Proxy validity: 12:00 Secgsi Proxy dep length: 0 Secgsi Proxy bits: 512 Secgsi Proxy sign option: 1 Secgsi Proxy delegation option: 0 Secgsi Pure Cert/Key authentication allowed Secgsi Allowed server names: [*/]<target host name>[/*] Secgsi Crypto modules: ssl Secgsi Ciphers: aes-128-cbc:bf-cbc:des-ede3-cbc Secgsi MDigests: sha1:md5 Secgsi Trusting DNS for hostname checking Secgsi ------------------------------------------------------------------- sec_PM: Using gsi protocol, args='v:10600,c:ssl,ca:5168735f.0|4339b4bc.0' [2023-02-02 15:47:06.256069 +0100][Debug ][XRootDTransport ] [eosalice:1094.0] Trying to authenticate using gsi 230202 15:47:09 32129 cryptossl_X509::CertType: certificate has 10 extensions 230202 15:47:09 32129 secgsi_VerifyCA: Warning: CA certificate not self-signed and integrity not checked: assuming OK (5168735f.0) 230202 15:47:09 32129 cryptossl_X509::CertType: certificate has 10 extensions 230202 15:47:09 32129 cryptossl_X509::CertType: certificate has 2 extensions 230202 15:47:09 32129 cryptossl_X509::CertType: certificate has 10 extensions [2023-02-02 15:47:09.114064 +0100][Dump ][AsyncSock ] [eosalice:1094.0] Wrote a message: (0xf8089e30), 136 bytes ``` Stracing another case shows, that the first thing happening after the several seconds of "nothing" is loading of a certificate (in this case the CERN ROOT certificate): **Subject: DC=ch, DC=cern, CN=CERN Grid Certification Authority** ``` [pid 14786] 1675334168.351985 access("/etc/grid-security/certificates/5168735f.0", R_OK) = 0 <0.000085> [pid 14786] 1675334168.352176 open("/etc/grid-security/certificates/5168735f.0", O_RDONLY) = 14 <0.000034> ``` The strace and client debug output are available on: ``` -rw-r--r--. 1 apeters vl 331555 Feb 2 11:39 slow_gsi_handshake_5.5.1 -rw-r--r--. 1 apeters vl 67694 Feb 2 15:53 slow_gsi_handshake_5.5.1.secdebug -bash-4.2$ pwd /afs/cern.ch/user/a/apeters/public ``` -- Reply to this email directly or view it on GitHub: https://github.com/xrootd/xrootd/issues/1892 You are receiving this because you are subscribed to this thread. 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