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, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <xrootd/xrootd/issues/1892@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