Bug #42984 | rpl.rpl_ssl1 fails in PB2 | ||
---|---|---|---|
Submitted: | 18 Feb 2009 18:39 | Modified: | 11 Dec 2009 9:45 |
Reporter: | Alexander Nozdrin | Email Updates: | |
Status: | Closed | Impact on me: | |
Category: | Tests: Replication | Severity: | S3 (Non-critical) |
Version: | 6.0-TRUNK,5.4 | OS: | Any |
Assigned to: | Libing Song | CPU Architecture: | Any |
Tags: | experimental, pb2, test failure |
[18 Feb 2009 18:39]
Alexander Nozdrin
[19 Sep 2009 11:08]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/83794 2817 Li-Bing.Song@sun.com 2009-09-19 BUG#42984 rpl.rpl_ssl1 fails in PB2 There are two problems need to be resolved: P1, $master_binlog_name_sql's value is NULL, this leads the error showed in this report. $master_binlog_name_sql's value is equal to the value of Master_Log_File which appears in slave status. The 'CHANGE MASTER' operation resets Master_Log_File as NULL if 'master_log_file' option is not assigned. This problem can be resolved through adding code to show_rpl_debug_info.inc. "SHOW BINLOG EVENTS IN '$master_binlog_name_sql'" statement only be executed when $master_binlog_name_sql is not null. P2, The deeper reason of this bug is wait_for_slave_to_start timeout. Slave I/O thread fails connection. It is deep relative with that master_host is set as 'localhost' and this bug only be reproduced on techra47.norway.sun.com. I replaced all certs used in this test case with my certs in which the server's name is 127.0.0.1, then the test worked well. I found there is a bug in IPV6 environment. On my machine I added an entry in /etc/hosts. It is "::1 localhost". Thus, localhost will not resolve correctly. So I think this is not a bug of replication. Instead of using localhost, '127.0.0.1' is used as name in server's cert. P2 has be reported as a new bug.
[19 Sep 2009 11:28]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/83796 2817 Li-Bing.Song@sun.com 2009-09-19 BUG#42984 rpl.rpl_ssl1 fails in PB2 There are two problems need to be resolved: P1, $master_binlog_name_sql's value is NULL, this leads the error showed in this report. $master_binlog_name_sql's value is equal to the value of Master_Log_File which appears in slave status. The 'CHANGE MASTER' operation resets Master_Log_File as NULL if 'master_log_file' option is not assigned. This problem can be resolved through adding code to show_rpl_debug_info.inc. "SHOW BINLOG EVENTS IN '$master_binlog_name_sql'" statement only be executed when $master_binlog_name_sql is not null. P2, The deeper reason of this bug is wait_for_slave_to_start timeout. Slave I/O thread fails connection. It is deep relative with that master_host is set as 'localhost' and this bug only be reproduced on techra47.norway.sun.com. I replaced all certs used in this test case with my certs in which the server's name is 127.0.0.1, then the test worked well. I found there is a bug in IPV6 environment. On my machine I added an entry in /etc/hosts. It is "::1 localhost". Thus, localhost will not resolve correctly. So I think this is not a bug of replication. Instead of using localhost, '127.0.0.1' is used as name in server's cert. P2 has be reported as a new bug. @ mysql-test/suite/rpl/t/rpl_ssl1.cnf Default certificates are replaced by these certificates which are added into this patch.
[24 Sep 2009 9:40]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/84464 2817 Li-Bing.Song@sun.com 2009-09-24 BUG#42984 rpl.rpl_ssl1 fails in PB2 There are two problems need to be resolved: P1, $master_binlog_name_sql's value is NULL, this leads the error showed in this report. $master_binlog_name_sql's value is equal to the value of Master_Log_File which appears in slave status. The 'CHANGE MASTER' operation resets Master_Log_File as NULL if 'master_log_file' option is not assigned. This problem can be resolved through adding code to show_rpl_debug_info.inc. "SHOW BINLOG EVENTS IN '$master_binlog_name_sql'" statement only be executed when $master_binlog_name_sql is not null. P2, The deeper reason of this bug is wait_for_slave_to_start timeout. Slave I/O thread fails connection. It is deep relative with that master_host is set as 'localhost' and this bug only be reproduced on techra47.norway.sun.com. I replaced all certs used in this test case with my certs in which the server's name is 127.0.0.1, then the test worked well. I found there is a bug in IPV6 environment. On my machine I added an entry in /etc/hosts. It is "::1 localhost". Thus, localhost will not resolve correctly. So I think this is not a bug of replication. Instead of using localhost, '127.0.0.1' is used as name in server's cert. P2 has be reported as a new bug, it is bug_47451. @ mysql-test/suite/rpl/t/rpl_ssl1.cnf Default certificates are replaced by these certificates which are added into this patch.
[28 Sep 2009 10:51]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/84824 2817 Li-Bing.Song@sun.com 2009-09-28 BUG#42984 rpl.rpl_ssl1 fails in PB2 There are two problems need to be resolved: P1, The execution of 'SHOW BINLOG EVENTS ...' statement causes the error showed in this report, when the value of 'master_binlog_name_sql' variable is NULL. $master_binlog_name_sql's value is equal to the value of Master_Log_File which appears in slave status. The value of the 'master_binlog_name_sql' variable will be set to NULL by 'CHANGE MASTER' operation, if the 'master_log_file' option is not assigned. P2, The deeper reason of this bug is wait_for_slave_to_start timeout. Slave I/O thread fails connection. It is deep relative with that master_host is set as 'localhost' and this bug only be reproduced on techra47.norway.sun.com. I found there is a bug in IPV6 environment. So I think this is not a bug of replication. To fix P1, the "SHOW BINLOG EVENTS ..." statement just can be executed when the value of $master_binlog_name_sql is not null. P2 has be reported as a new bug, it is bug_47451. Instead of using localhost, '127.0.0.1' is used as name in server's cert. rpl_ssl1 will not reproduce this bug again. @ mysql-test/suite/rpl/t/rpl_ssl1.cnf Default certificates are replaced by these certificates which are added into this patch.
[1 Oct 2009 14:25]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/85392 3633 Li-Bing.Song@sun.com 2009-10-01 BUG#42984 rpl.rpl_ssl1 fails in PB2 There are two problems need to be resolved: P1, The execution of 'SHOW BINLOG EVENTS ...' statement causes the error showed in this report, when the value of 'master_binlog_name_sql' variable is NULL. $master_binlog_name_sql's value is equal to the value of Master_Log_File which appears in slave status. The value of the 'master_binlog_name_sql' variable will be set to NULL by 'CHANGE MASTER' operation, if the 'master_log_file' option is not assigned. P2, The deeper reason of this bug is wait_for_slave_to_start timeout. Slave I/O thread fails connection. It is deep relative with that master_host is set as 'localhost' and this bug only be reproduced on techra47.norway.sun.com. I found there is a bug in IPV6 environment. So I think this is not a bug of replication. To fix P1, the "SHOW BINLOG EVENTS ..." statement just can be executed when the value of $master_binlog_name_sql is not null. P2 has be reported as a new bug, it is bug_47451. Instead of using localhost, '127.0.0.1' is used as name in server's cert. rpl_ssl1 will not reproduce this bug again.
[1 Oct 2009 14:35]
Libing Song
Pushed to mysql-6.0-codebase-bugfixing
[6 Oct 2009 7:57]
Alexander Nozdrin
Now it regularly fails on HPUX: 091005 22:50:29 [ERROR] /export/tmp/pb2/test/sb_1-794120-1254763559.27/mysql-6.0.14-alpha-hpux11.31-ia64-test/libexec/mysqld: unknown variable 'ssl-ca=../../../std_data/ca.cert' 091005 22:50:29 [ERROR] Aborting It started to fail after Oct-2: http://pb2.norway.sun.com/web.py?template=mysql_show_test_failure&test_failure_id=2366998&... The test case marked experimental on HPUX due to this bug.
[9 Oct 2009 8:47]
Bugs System
Pushed into 6.0.14-alpha (revid:alik@ibmvm-20091009083208-0o0f0i9w1sq3c1kn) (version source revid:guilhem@mysql.com-20091006081216-gpmo5wki9if2y9gt) (merge vers: 6.0.14-alpha) (pib:12)
[16 Oct 2009 6:16]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/87066 3653 Li-Bing.Song@sun.com 2009-10-16 BUG#42984 rpl.rpl_ssl1 fails in PB2 Postfix On PB2's HP Unix machines, Mysqld reported an error "unknow ssl-ca option" and then aborted itself when it was initializing options. PB2's HP Unix machines do not support ssl, so they do not know ssl-* options. if 'loose-' prefix is appearing, mysqld only gives a warnings and then gose on. Before this patch, mtr treats ssl-* and loose-ssl-* as different options. Both the default ssl-* options and the prive loose-ssl-* options in rpl_ssl1.cnf are written into my.cnf. Instead of the private certificates, Default certificates are using in the test. After this patch, mtr treats ssl-* options as same as loose-ssl-* options. @ mysql-test/lib/My/Config.pm
[16 Oct 2009 10:40]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/87104 3653 Li-Bing.Song@sun.com 2009-10-16 BUG#42984 rpl.rpl_ssl1 fails in PB2 Postfix On PB2's HP Unix machines, Mysqld reported an error "unknow ssl-ca option" and then aborted itself when it was initializing options. PB2's HP Unix machines do not support ssl, but the ssl options in private cnf(rpl_ssl1.cnf) are still written into my.cnf, so mysqlds do not know ssl-* options. Before this patch, Default ssl-* options are not added into my.cnf if ssl is not supported, but the ssl-* options in private cnf(rpl_ssl1.cnf) are still copied into my.cnf. After this patch, Both the default ssl-* options and the private ssl-* options are not copied into my.cnf if ssl is not supported. @ mysql-test/lib/My/Config.pm
[19 Oct 2009 11:12]
Bjørn Munch
I see that this had already been pushed before the latest MTR patch. I was asked to look at it and came up with a more general fix which will make MTR ignore SSL tests if the server does not support it, the way it now does for e.g. innodb tests. Perhaps it would be more appropriate to file that as a separate MTR bug and for me to push that?
[20 Oct 2009 4:41]
Libing Song
The fails on HPUX has been reported by Bjorn as a new bug#48149 which is just related to mtr.
[20 Oct 2009 13:40]
Jon Stephens
Change in test program only, no end-user changes to document. Closed.
[1 Dec 2009 2:36]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/92202 3740 Li-Bing.Song@sun.com 2009-12-01 The patch for Bug#42984 has been pushed.
[1 Dec 2009 3:16]
Bugs System
A patch for this bug has been committed. After review, it may be pushed to the relevant source trees for release in the next version. You can access the patch from: http://lists.mysql.com/commits/92203 3740 Li-Bing.Song@sun.com 2009-12-01 The patch for Bug#42984 has been pushed. So rpl_ssl1 is removed from default.experimental
[11 Dec 2009 6:01]
Bugs System
Pushed into 6.0.14-alpha (revid:alik@sun.com-20091211055901-yp18b3c7xuhl87rf) (version source revid:alik@sun.com-20091211055401-43rjwq7gjed6ds83) (merge vers: 6.0.14-alpha) (pib:13)
[11 Dec 2009 9:45]
Jon Stephens
Re-closing; see my comment of 20 October.