[MDEV-20614] Syntax error, and option put in wrong place, in mysqld_multi perl script - Jira

Details

Type: Bug
Status: Closed (View Workflow)
Priority: Blocker
Resolution: Fixed
Affects Version/s: 10.2.27, 10.3.18, 10.4.8
Fix Version/s: 10.2.28, 10.1.42, 10.3.19, 10.4.9
Component/s: Scripts & Clients
Labels:
None

Description

Current mysqld_multi perl script fails due to a syntax error introduced a syntax error due to use of elseif instead of perl elsif

The following one character change fixes this:

diff --git a/scripts/mysqld_multi.sh b/scripts/mysqld_multi.sh

index b8730e2624a..748925bef0b 100644

--- a/scripts/mysqld_multi.sh

+++ b/scripts/mysqld_multi.sh

@@ -349,7 +349,7 @@ sub start_mysqlds()

         $options[$j]= quote_shell_word($options[$j]);

         $tmp.= " $options[$j]";

-      elseif ("--defaults-group-suffix=" eq substr($options[$j], 0, 24))

+      elsif ("--defaults-group-suffix=" eq substr($options[$j], 0, 24))

         $suffix_found= 1;

But even with this fixed mysqld_multi can't start any server instance, as the new code in 10.3.18 does not pass --defaults-group-suffix as the very first option to mysqld, as required.

The following should fix this for the default case, where mysqld in the [mysqld_multi] section is either given as mysqld or mysqld_multi, as expected. It will fail though if mysqld setting already contains a command line setting by itself ...

@@ -368,7 +368,6 @@ sub start_mysqlds()

       print "wanted mysqld binary.\n\n";

       $info_sent= 1;

-    $com.= $tmp;

     if (!$suffix_found)

@@ -376,6 +375,8 @@ sub start_mysqlds()

       $com.= $groups[$i];

+    $com.= $tmp;

     if ($opt_wsrep_new_cluster) {

       $com.= " --wsrep-new-cluster";

Both problems were introduced by commit commit 137d8ed3fee14335bd707474bd49f4e43b3bf309
for ~~MDEV-18863~~

Attachments

- Sort By Name
- Sort By Date
- Ascending
- Descending
- Thumbnails
- List
- Download All

screenshot-1.png
154 kB
2019-10-05 10:47

Issue Links

causes

MDEV-21039 Server fails to start with mysqld_multi with mysqld_safe options

Closed

is caused by

MDEV-18863 Galera SST scripts can't read mysqld_multi's [mysqldN] option groups

Closed

relates to

MDEV-20728 /usr/sbin/mysqld: unknown variable 'defaults-group-suffix=mysqld1

Closed

MDEV-20868 mysqld_multi failed to run due to a basic script syntax error

Closed

links to

PR #1388

PR #1390

(1 links to)

Activity

Ascending order - Click to sort in descending order

Hartmut Holzgraefe created issue - 2019-09-18 08:34

Hartmut Holzgraefe made changes - 2019-09-18 08:37

Field	Original Value	New Value
Link		This issue is caused by ~~MDEV-18863~~ [ ~~MDEV-18863~~ ]

Hartmut Holzgraefe made changes - 2019-09-18 08:37

Description	Current mysqld_multi perl script fails due to a syntax error introduced a syntax error due to use of +elseif+ instead of perl +elsif+ The following one character change fixes this: {{noformat}} diff --git a/scripts/mysqld_multi.sh b/scripts/mysqld_multi.sh index b8730e2624a..748925bef0b 100644 --- a/scripts/mysqld_multi.sh +++ b/scripts/mysqld_multi.sh @@ -349,7 +349,7 @@ sub start_mysqlds() $options[$j]= quote_shell_word($options[$j]); $tmp.= " $options[$j]"; } - elseif ("--defaults-group-suffix=" eq substr($options[$j], 0, 24)) + elsif ("--defaults-group-suffix=" eq substr($options[$j], 0, 24)) { $suffix_found= 1; } {{noformat}} But even with this fixed mysqld_multi can't start any server instance, as the new code in 10.3.18 does not pass --defaults-group-suffix as the very first option to mysqld, as required. The following should fix this for the default case, where +mysqld+ in the +[mysqld_multi]+ section is either given as +mysqld+ or +mysqld_multi+, as expected. It will fail though if +mysqld+ setting already contains a command line setting by itself ... {noformat} @@ -368,7 +368,6 @@ sub start_mysqlds() print "wanted mysqld binary.\n\n"; $info_sent= 1; } - $com.= $tmp; if (!$suffix_found) { @@ -376,6 +375,8 @@ sub start_mysqlds() $com.= $groups[$i]; } + $com.= $tmp; + if ($opt_wsrep_new_cluster) { $com.= " --wsrep-new-cluster"; } {noformat}	Current mysqld_multi perl script fails due to a syntax error introduced a syntax error due to use of +elseif+ instead of perl +elsif+ The following one character change fixes this: {{noformat}} diff --git a/scripts/mysqld_multi.sh b/scripts/mysqld_multi.sh index b8730e2624a..748925bef0b 100644 --- a/scripts/mysqld_multi.sh +++ b/scripts/mysqld_multi.sh @@ -349,7 +349,7 @@ sub start_mysqlds() $options[$j]= quote_shell_word($options[$j]); $tmp.= " $options[$j]"; } - elseif ("--defaults-group-suffix=" eq substr($options[$j], 0, 24)) + elsif ("--defaults-group-suffix=" eq substr($options[$j], 0, 24)) { $suffix_found= 1; } {{noformat}} But even with this fixed mysqld_multi can't start any server instance, as the new code in 10.3.18 does not pass --defaults-group-suffix as the very first option to mysqld, as required. The following should fix this for the default case, where +mysqld+ in the +[mysqld_multi]+ section is either given as +mysqld+ or +mysqld_multi+, as expected. It will fail though if +mysqld+ setting already contains a command line setting by itself ... {noformat} @@ -368,7 +368,6 @@ sub start_mysqlds() print "wanted mysqld binary.\n\n"; $info_sent= 1; } - $com.= $tmp; if (!$suffix_found) { @@ -376,6 +375,8 @@ sub start_mysqlds() $com.= $groups[$i]; } + $com.= $tmp; + if ($opt_wsrep_new_cluster) { $com.= " --wsrep-new-cluster"; } {noformat} Both problems were introduced by commit commit 137d8ed3fee14335bd707474bd49f4e43b3bf309 for ~~MDEV-18863~~
Summary	Syntax error in mysqld_multi perl script	Syntax error, and option put in wrong place, in mysqld_multi perl script

Hartmut Holzgraefe made changes - 2019-09-18 08:41

Affects Version/s

10.4.8 [ 23721 ]

Hartmut Holzgraefe made changes - 2019-09-18 08:42

Description

Current mysqld_multi perl script fails due to a syntax error introduced a syntax error due to use of +elseif+ instead of perl +elsif+

The following one character change fixes this:

{{noformat}}
diff --git a/scripts/mysqld_multi.sh b/scripts/mysqld_multi.sh
index b8730e2624a..748925bef0b 100644
--- a/scripts/mysqld_multi.sh
+++ b/scripts/mysqld_multi.sh
@@ -349,7 +349,7 @@ sub start_mysqlds()
         $options[$j]= quote_shell_word($options[$j]);
         $tmp.= " $options[$j]";
       }
- elseif ("--defaults-group-suffix=" eq substr($options[$j], 0, 24))
+ elsif ("--defaults-group-suffix=" eq substr($options[$j], 0, 24))
       {
         $suffix_found= 1;
       }
{{noformat}}

But even with this fixed mysqld_multi can't start any server instance, as the new code in 10.3.18 does not pass --defaults-group-suffix as the very first option to mysqld, as required.

The following should fix this for the default case, where +mysqld+ in the +[mysqld_multi]+ section is either given as +mysqld+ or +mysqld_multi+, as expected. It will fail though if +mysqld+ setting already contains a command line setting by itself ...

{noformat}
@@ -368,7 +368,6 @@ sub start_mysqlds()
       print "wanted mysqld binary.\n\n";
       $info_sent= 1;
     }
- $com.= $tmp;

     if (!$suffix_found)
     {
@@ -376,6 +375,8 @@ sub start_mysqlds()
       $com.= $groups[$i];
     }

+ $com.= $tmp;
+
     if ($opt_wsrep_new_cluster) {
       $com.= " --wsrep-new-cluster";
     }
{noformat}

Both problems were introduced by commit commit 137d8ed3fee14335bd707474bd49f4e43b3bf309
for ~~MDEV-18863~~

Current mysqld_multi perl script fails due to a syntax error introduced a syntax error due to use of +elseif+ instead of perl +elsif+

The following one character change fixes this:

{noformat}
diff --git a/scripts/mysqld_multi.sh b/scripts/mysqld_multi.sh
index b8730e2624a..748925bef0b 100644
--- a/scripts/mysqld_multi.sh
+++ b/scripts/mysqld_multi.sh
@@ -349,7 +349,7 @@ sub start_mysqlds()
         $options[$j]= quote_shell_word($options[$j]);
         $tmp.= " $options[$j]";
       }
- elseif ("--defaults-group-suffix=" eq substr($options[$j], 0, 24))
+ elsif ("--defaults-group-suffix=" eq substr($options[$j], 0, 24))
       {
         $suffix_found= 1;
       }
{noformat}

But even with this fixed mysqld_multi can't start any server instance, as the new code in 10.3.18 does not pass --defaults-group-suffix as the very first option to mysqld, as required.

The following should fix this for the default case, where +mysqld+ in the +[mysqld_multi]+ section is either given as +mysqld+ or +mysqld_multi+, as expected. It will fail though if +mysqld+ setting already contains a command line setting by itself ...

{noformat}
@@ -368,7 +368,6 @@ sub start_mysqlds()
       print "wanted mysqld binary.\n\n";
       $info_sent= 1;
     }
- $com.= $tmp;

     if (!$suffix_found)
     {
@@ -376,6 +375,8 @@ sub start_mysqlds()
       $com.= $groups[$i];
     }

+ $com.= $tmp;
+
     if ($opt_wsrep_new_cluster) {
       $com.= " --wsrep-new-cluster";
     }
{noformat}

Both problems were introduced by commit commit 137d8ed3fee14335bd707474bd49f4e43b3bf309
for ~~MDEV-18863~~

Elena Stepanova made changes - 2019-09-18 13:09

Fix Version/s		10.3 [ 22126 ]
Fix Version/s		10.4 [ 22408 ]
Assignee		Julius Goryavsky [ sysprg ]

Geoff Montee (Inactive) made changes - 2019-09-18 16:43

Fix Version/s		10.1 [ 16100 ]
Fix Version/s		10.2 [ 14601 ]

Sergei Golubchik made changes - 2019-09-19 16:23

Priority

Critical [ 2 ]

Blocker [ 1 ]

Geoff Montee (Inactive) made changes - 2019-09-20 17:05

Affects Version/s

10.2.27 [ 23717 ]

Julius Goryavsky made changes - 2019-09-23 23:09

Status

Open [ 1 ]

In Progress [ 3 ]

Julius Goryavsky added a comment - 2019-10-01 09:19

Fixed, https://github.com/MariaDB/server/commit/2fba8f72a8ab560b87578830fafb51bd26c809ab

Julius Goryavsky added a comment - 2019-10-01 09:19 Fixed, https://github.com/MariaDB/server/commit/2fba8f72a8ab560b87578830fafb51bd26c809ab

Julius Goryavsky made changes - 2019-10-01 09:19

Fix Version/s		10.1.45 [ 23913 ]
Fix Version/s		10.2.29 [ 23911 ]
Fix Version/s		10.3.20 [ 23909 ]
Fix Version/s		10.4.10 [ 23907 ]
Fix Version/s	10.2 [ 14601 ]
Fix Version/s	10.1 [ 16100 ]
Fix Version/s	10.3 [ 22126 ]
Fix Version/s	10.4 [ 22408 ]
Resolution		Fixed [ 1 ]
Status	In Progress [ 3 ]	Closed [ 6 ]

Geoff Montee (Inactive) added a comment - 2019-10-01 23:08 - edited

The "Fix Version/s" field for this bug report is set to the following: "10.1.45, 10.2.29, 10.3.20, 10.4.10".

Is that really correct? It looks wrong to me.

Shouldn't the "Fix Version/s" field be set to the next versions in each release series, which would mean the following?: "10.1.42, 10.2.28, 10.3.19, 10.4.9"

Also, it doesn't look like the fix has been pushed to the main 10.1 branch yet.

Geoff Montee (Inactive) added a comment - 2019-10-01 23:08 - edited The "Fix Version/s" field for this bug report is set to the following: "10.1.45, 10.2.29, 10.3.20, 10.4.10". Is that really correct? It looks wrong to me. Shouldn't the "Fix Version/s" field be set to the next versions in each release series, which would mean the following?: "10.1.42, 10.2.28, 10.3.19, 10.4.9" Also, it doesn't look like the fix has been pushed to the main 10.1 branch yet.

Geoff Montee (Inactive) made changes - 2019-10-04 21:47

Link

This issue relates to ~~MDEV-20728~~ [ ~~MDEV-20728~~ ]

Julius Goryavsky added a comment - 2019-10-04 23:05

Fix is already pushed to the main branch for 10.1 (commit 144217339d8dc2d6e00542cd25d97e39b90afa3f, in the main branch since Sep 25 2019, 14:00:39) and it is pushed to the main branch for 10.2 (commit bc70862e13f32756695d5781c793f2525aeb7187) and then merged with 10.3 and 10.4 (there same commit id). Perhaps I indicated the wrong version numbers on JIRA because I just selected the latter in the list.

Julius Goryavsky added a comment - 2019-10-04 23:05 Fix is already pushed to the main branch for 10.1 (commit 144217339d8dc2d6e00542cd25d97e39b90afa3f, in the main branch since Sep 25 2019, 14:00:39) and it is pushed to the main branch for 10.2 (commit bc70862e13f32756695d5781c793f2525aeb7187) and then merged with 10.3 and 10.4 (there same commit id). Perhaps I indicated the wrong version numbers on JIRA because I just selected the latter in the list.

Geoff Montee (Inactive) added a comment - 2019-10-04 23:33

Hi sysprg,

Fix is already pushed to the main branch for 10.1 (commit 144217339d8dc2d6e00542cd25d97e39b90afa3f, in the main branch since Sep 25 2019, 14:00:39)

Hmm, weird. GitHub shows that commit 144217339d8dc2d6e00542cd25d97e39b90afa3f has only been pushed to the 10.5 branch:

https://github.com/MariaDB/server/commit/144217339d8dc2d6e00542cd25d97e39b90afa3f

and it is pushed to the main branch for 10.2 (commit bc70862e13f32756695d5781c793f2525aeb7187) and then merged with 10.3 and 10.4 (there same commit id).

GitHub shows that commit bc70862e13f32756695d5781c793f2525aeb7187 has also only been pushed to the 10.5 branch:

https://github.com/MariaDB/server/commit/bc70862e13f32756695d5781c793f2525aeb7187

I'm not sure if GitHub is wrong, or if something went wrong with your pushes.

Perhaps I indicated the wrong version numbers on JIRA because I just selected the latter in the list.

I don't believe that selecting the last in the list is the proper method. I believe that the proper method is to pick the first releases in the "Unreleased Versions" list.

Geoff Montee (Inactive) added a comment - 2019-10-04 23:33 Hi sysprg , Fix is already pushed to the main branch for 10.1 (commit 144217339d8dc2d6e00542cd25d97e39b90afa3f, in the main branch since Sep 25 2019, 14:00:39) Hmm, weird. GitHub shows that commit 144217339d8dc2d6e00542cd25d97e39b90afa3f has only been pushed to the 10.5 branch: https://github.com/MariaDB/server/commit/144217339d8dc2d6e00542cd25d97e39b90afa3f and it is pushed to the main branch for 10.2 (commit bc70862e13f32756695d5781c793f2525aeb7187) and then merged with 10.3 and 10.4 (there same commit id). GitHub shows that commit bc70862e13f32756695d5781c793f2525aeb7187 has also only been pushed to the 10.5 branch: https://github.com/MariaDB/server/commit/bc70862e13f32756695d5781c793f2525aeb7187 I'm not sure if GitHub is wrong, or if something went wrong with your pushes. Perhaps I indicated the wrong version numbers on JIRA because I just selected the latter in the list. I don't believe that selecting the last in the list is the proper method. I believe that the proper method is to pick the first releases in the "Unreleased Versions" list.

Julius Goryavsky made changes - 2019-10-05 10:47

Attachment

screenshot-1.png [ 49086 ]

Julius Goryavsky added a comment - 2019-10-05 10:47

Hi, GeoffMontee,

Perhaps github does not display all the branches - for verification, you can simply select branch 10.1 and see the list of commits for it (screeenshot attached) or switch to 10.1 and see git log for it on the command line:

................

................

commit 144217339d8dc2d6e00542cd25d97e39b90afa3f

Author: Julius Goryavsky <julius.goryavsky@mariadb.com>

Date:   Wed Sep 25 14:00:39 2019 +0200

    MDEV-20614: Syntax error, and option put in wrong place

    A syntax error in the mysqld_multi.sh script has been fixed

    here + a "--defaults-group-suffix" option has been moved to

    the top of the mysqld options list.

................

Julius Goryavsky added a comment - 2019-10-05 10:47 Hi, GeoffMontee , Perhaps github does not display all the branches - for verification, you can simply select branch 10.1 and see the list of commits for it (screeenshot attached) or switch to 10.1 and see git log for it on the command line: ................ ................ commit 144217339d8dc2d6e00542cd25d97e39b90afa3f Author: Julius Goryavsky <julius.goryavsky@mariadb.com> Date: Wed Sep 25 14:00:39 2019 +0200 MDEV-20614: Syntax error, and option put in wrong place A syntax error in the mysqld_multi.sh script has been fixed here + a "--defaults-group-suffix" option has been moved to the top of the mysqld options list. ................

Anel Husakovic made changes - 2019-10-22 09:01

Link

This issue relates to ~~MDEV-20868~~ [ ~~MDEV-20868~~ ]

Anel Husakovic made changes - 2019-10-22 09:04

Remote Link

This issue links to "PR #1390 (Web Link)" [ 29302 ]

Anel Husakovic made changes - 2019-10-22 09:04

Remote Link

This issue links to "PR #1388 (Web Link)" [ 29303 ]

Anel Husakovic added a comment - 2019-10-22 09:12

Hi sysprg,
I don't see commits from PR #1388 and PR #1390 from contributor?
Here is a history 10.5/

Anel Husakovic added a comment - 2019-10-22 09:12 Hi sysprg , I don't see commits from PR #1388 and PR #1390 from contributor? Here is a history 10.5 /

Julius Goryavsky made changes - 2019-10-29 13:14

Fix Version/s		10.1.42 [ 23407 ]
Fix Version/s		10.2.28 [ 23910 ]
Fix Version/s		10.3.19 [ 23908 ]
Fix Version/s		10.4.9 [ 23906 ]
Fix Version/s	10.4.10 [ 23907 ]
Fix Version/s	10.3.20 [ 23909 ]
Fix Version/s	10.2.29 [ 23911 ]
Fix Version/s	10.1.45 [ 23913 ]

Geoff Montee (Inactive) made changes - 2019-11-12 21:14

Link

This issue causes ~~MDEV-21039~~ [ ~~MDEV-21039~~ ]

Sergei Golubchik made changes - 2021-12-06 21:50

Workflow

MariaDB v3 [ 99731 ]

MariaDB v4 [ 156758 ]

Jira Automation (IT) made changes - 2024-07-04 03:32

Zendesk Related Tickets

185982 107273

People

Assignee:: Julius Goryavsky

Reporter:: Hartmut Holzgraefe

Votes:: 0 Vote for this issue

Watchers:: 7 Start watching this issue

Dates

Created:: 2019-09-18 08:34

Updated:: 2024-07-07 22:44

Resolved:: 2019-10-01 09:19

Git Integration

Error rendering 'com.xiplink.jira.git.jira_git_plugin:git-issue-webpanel'. Please contact your Jira administrators.

MariaDB Server

Details

Description

Attachments

Attachments

Issue Links

Activity

People

Dates

Git Integration