[MDEV-7178] wsrep* tests fail in buildbot Created: 2014-11-23  Updated: 2015-02-05  Resolved: 2015-02-05

Status: Closed
Project: MariaDB Server
Component/s: Galera, Tests
Affects Version/s: 10.1
Fix Version/s: 10.1.3

Type: Bug Priority: Critical
Reporter: Elena Stepanova Assignee: Jan Lindström (Inactive)
Resolution: Fixed Votes: 0
Labels: buildbot, tests

Attachments: File mysqld.diff    
Issue Links:
Blocks
blocks MDEV-7069 Fix buildbot failures in main server ... Stalled
blocks MDEV-7172 Fix buildbot failures in 10.1 tree Closed

 Description   

http://buildbot.askmonty.org/buildbot/builders/kvm-deb-lucid-amd64/builds/4066/steps/test_4/logs/stdio

wsrep.binlog_format 'innodb_plugin'      w1 [ fail ]
 
        Test ended at 2014-11-23 16:56:54
 
 
 
CURRENT_TEST: wsrep.binlog_format
 
 
 
 
 
Failed to start mysqld.1
 
mysqltest failed but provided no output
 

wsrep.pool_of_threads 'innodb_plugin'    w3 [ fail ]
 
        Test ended at 2014-11-23 16:57:18
 
 
 
CURRENT_TEST: wsrep.pool_of_threads
 
 
 
 
 
Failed to start mysqld.1
 
mysqltest failed but provided no output
 

wsrep.partition 'innodb_plugin'          w1 [ fail ]
 
        Test ended at 2014-11-23 16:57:21
 
 
 
CURRENT_TEST: wsrep.partition
 
 
 
 
 
Failed to start mysqld.1
 
mysqltest failed but provided no output
 

wsrep.grant 'innodb_plugin'              w2 [ fail ]
 
        Test ended at 2014-11-23 16:57:21
 
 
 
CURRENT_TEST: wsrep.grant
 
 
 
 
 
Could not execute 'check-testcase' before testcase 'wsrep.grant' (res: 1):
 
mysqltest: Logging to '/dev/shm/var/2/tmp/check-mysqld_1.log'.
 
mysqltest: Results saved in '/dev/shm/var/2/tmp/check-mysqld_1.result'.
 
mysqltest: Connecting to server localhost:16020 (socket /dev/shm/var/tmp/2/mysqld.1.sock) as 'root', connection 'default', attempt 0 ...
 
mysqltest: ... Connected.
 
mysqltest: Start processing test commands from './include/check-testcase.test' ...
 
mysqltest: At line 75: Failed to write 55151 bytes to '/dev/shm/var/2/tmp/check-mysqld_1.log', errno: 28
 
not ok
 
mysqltest failed but provided no output



 Comments   
Comment by Elena Stepanova [ 2014-12-06 ]

http://buildbot.askmonty.org/buildbot/builders/kvm-deb-debian6-x86/builds/3398/steps/test_4/logs/stdio

wsrep.basic 'innodb_plugin'              w2 [ fail ]  Found warnings/errors in server log file!
 
        Test ended at 2014-12-06 06:42:16
 
line
 
141206  6:42:04 [Warning] WSREP: no nodes coming from prim view, prim not possible
 
^ Found warnings in /dev/shm/var/2/log/mysqld.2.err
 
ok
 
 
 
 - saving '/dev/shm/var/2/log/wsrep.basic-innodb_plugin/' to '/dev/shm/var/log/wsrep.basic-innodb_plugin/'

Comment by Jan Lindström (Inactive) [ 2015-01-21 ] 

export PATH=$PATH:/usr/local/mysql/bin

and problem dissapears.

Comment by Nirbhay Choubey (Inactive) [ 2015-01-21 ]

jplindst it can possibly be because the control somehow skips wsrep_prepend_PATH() :

 4985     else // full wsrep initialization
 
 4986     {
 
 4987       // add basedir/bin to PATH to resolve wsrep script names
 
 4988       char* const tmp_path= (char*)my_alloca(strlen(mysql_home) +
 
 4989                                              strlen("/bin") + 1);
 
 4990       if (tmp_path)
 
 4991       {
 
 4992         strcpy(tmp_path, mysql_home);
 
 4993         strcat(tmp_path, "/bin");
 
 4994         wsrep_prepend_PATH(tmp_path);
 
 4995       }
 
 4996       else

Comment by Jan Lindström (Inactive) [ 2015-01-27 ]

Problem is that mysql_home is e.g. my case /home/jan/10.1/ but there is no bin directory, we should also add /scripts directory to path.

Comment by Jan Lindström (Inactive) [ 2015-01-27 ]

Suggested (tested) patch:

diff --git a/sql/mysqld.cc b/sql/mysqld.cc
 
index ea53e47..d048384 100644
 
--- a/sql/mysqld.cc
 
+++ b/sql/mysqld.cc
 
@@ -4999,6 +4999,24 @@ a file name for --log-bin-index option", opt_binlog_index_name);
 
       }
 
       my_afree(tmp_path);
 
 
+
 
+      // add scripts to PATH for mysql-test-run to find wsrep
 
+      // script names
 
+      char* const tmp_path2= (char*)my_alloca(strlen(mysql_home) +
 
+                                             strlen("/scripts") + 1);
 
+      if (tmp_path2)
 
+      {
 
+        strcpy(tmp_path2, mysql_home);
 
+        strcat(tmp_path2, "/scripts");
 
+        wsrep_prepend_PATH(tmp_path2);
 
+      }
 
+      else
 
+      {
 
+        WSREP_ERROR("Could not append %s/scripts to PATH", mysql_home);
 
+      }
 
+
 
+      my_afree(tmp_path2);
 
+
 
       if (wsrep_before_SE())
 
       {
 
         set_ports(); // this is also called in network_init() later but we need

Comment by Sergei Golubchik [ 2015-01-28 ]

wsrep_prepend_PATH() is only used in mysqld.cc, in this specific place.
So, I'd suggest to move this whole block of code into wsrep_prepend_PATH() and not repeat it twice in the caller. Then mysqld.cc would only have

  wsrep_prepend_PATH(mysql_home, "bin");
 
  wsrep_prepend_PATH(mysql_home, "scripts");

Comment by Sergei Golubchik [ 2015-01-28 ]

On the other hand…
suite/wsrep/suite.pm normally adds scripts and extra to the path. Why does that not happen in your case?

Comment by Jan Lindström (Inactive) [ 2015-01-29 ]

There is some kind of timing problem, it does add those to the path, second run of mtr succeeds but not the first one !

Comment by Sergei Golubchik [ 2015-01-29 ]

I don't see how that can be timing, the code in suite.pm is very deterministic:

my ($spath) = grep { -f "$_/wsrep_sst_rsync"; } "$::bindir/scripts", $::path_client_bindir;
 
my ($epath) = grep { -f "$_/my_print_defaults"; } "$::bindir/extra", $::path_client_bindir;
 
$ENV{PATH}="$epath:$ENV{PATH}";
 
$ENV{PATH}="$spath:$ENV{PATH}" unless $epath eq $spath;

Comment by Jan Lindström (Inactive) [ 2015-01-29 ]

Path has nothing to do with this. We are hitting https://github.com/codership/galera/issues/204

Comment by Jan Lindström (Inactive) [ 2015-02-05 ]

commit b08126aad1a33ec0ad3491b061e888908d1edfe5
Author: Jan Lindström <jan.lindstrom@skysql.com>
Date: Thu Feb 5 08:52:17 2015 +0200

MDEV-7178: wsrep* tests fail in buildbot

This is temporal test fixt to avoid concurrent IST for now until
the actual issue https://github.com/codership/galera/issues/204
is fixed.

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