[MDEV-11244] main.ssl_timeout failed in buildbot Created: 2016-11-07  Updated: 2023-11-29  Resolved: 2023-11-29

Status: Closed
Project: MariaDB Server
Component/s: Tests
Affects Version/s: 10.2
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Georg Richter
Resolution: Won't Fix Votes: 0
Labels: 10.2-ga

Issue Links:
Relates
relates to MDEV-7069 Fix buildbot failures in main server ... Stalled

 Description   

http://buildbot.askmonty.org/buildbot/builders/kvm-deb-xenial-amd64/builds/547/steps/test_5/logs/stdio

main.ssl_timeout                         w1 [ fail ]
 
        Test ended at 2016-11-04 15:38:42
 
 
 
CURRENT_TEST: main.ssl_timeout
 
mysqltest: At line 10: query 'SELECT (VARIABLE_VALUE <> '') AS have_ssl FROM INFORMATION_SCHEMA.SESSION_STATUS WHERE VARIABLE_NAME='Ssl_cipher'' failed: 2013: Lost connection to MySQL server during query
 
 
 
The result from queries just before the failure was:
 
# connect with read timeout so SLEEP() should timeout
 
connect  ssl_con,localhost,root,,,,,SSL read_timeout=5;
 
# Check ssl turned on
 
SELECT (VARIABLE_VALUE <> '') AS have_ssl FROM INFORMATION_SCHEMA.SESSION_STATUS WHERE VARIABLE_NAME='Ssl_cipher';
 
 
 
 - skipping '/dev/shm/var/1/log/main.ssl_timeout/'



 Comments   
Comment by Vladislav Vaintroub [ 2016-11-08 ]

this one is sporadic, but at the very least I'd like to have errors from the lowest level (ssl) to be properly propagated to the upper level. "Lost connection during query" has no details.

There should be SSL error , or socket error there. If the socket was closed on the server side
(as indicated by recv() returning 0), it should say "server closed the connection".

mysqld did not crash here btw.

Comment by Georg Richter [ 2017-01-25 ]

We have at least two options to fix this:

1) Using pvio->read/write instead of SSL_read/SSL_write by registering these function via BIO_method (that would allow also to communicate via non socket connections).

2) Using non-blocking and checking error codes and timeout.

Generated at Thu Feb 08 07:48:26 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.