Details
-
Bug
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
10.4.7, 10.4.10
-
3 Node Galera Cluster - MariaDB 10.4.7 Enterprise on RHEL 7.6
Description
when trying to start mariadb via systemctl, I'm getting this error:
WSREP: Failed to start mysqld for wsrep recovery: '/usr/local/mysql/bin/galera_recovery: line 71: ./bin/mysqld: No such file or directory'
|
seems that the binary "galera-recovery" is neither searching the mysqld in the same folder as the binary itself nor in the path variable but instead expects the root to be /usr/local/mysql
Workaround: I just modified line 77 of "mariadb.service":
#before:
|
VAR=`/usr/local/mysql/bin/galera_recovery`; [ $? -eq 0 ] \
|
#after
|
VAR=`cd /usr/local/mysql; /usr/local/mysql/bin/galera_recovery`; [ $? -eq 0 ] \
|
Attachments
Activity
| Field | Original Value | New Value |
|---|---|---|
| Description |
when trying to start mariadb via systemctl, I'm getting this error:
{code} WSREP: Failed to start mysqld for wsrep recovery: '/usr/local/mysql/bin/galera_recovery: line 71: ./bin/mysqld: No such file or directory' {code} seems that the binary "galera-recovery" is neither searching the mysqld in the same folder as the binary itself nor in the path variable but instead expects the root to be /usr/local/mysql Workaround: I just modified line 77 of "mariadb.service": {code} #before: VAR=`/usr/local/mysql/bin/galera_recovery`; [ $? -eq 0 ] \ #after VAR=`cd /usr/local/mysql; /usr/local/mysql/bin/galera_recovery`; [ $? -eq 0 ] \ {/code} |
when trying to start mariadb via systemctl, I'm getting this error:
{code} WSREP: Failed to start mysqld for wsrep recovery: '/usr/local/mysql/bin/galera_recovery: line 71: ./bin/mysqld: No such file or directory' {code} seems that the binary "galera-recovery" is neither searching the mysqld in the same folder as the binary itself nor in the path variable but instead expects the root to be /usr/local/mysql Workaround: I just modified line 77 of "mariadb.service": {code} #before: VAR=`/usr/local/mysql/bin/galera_recovery`; [ $? -eq 0 ] \ #after VAR=`cd /usr/local/mysql; /usr/local/mysql/bin/galera_recovery`; [ $? -eq 0 ] \ {code} |
| Assignee | Julius Goryavsky [ sysprg ] |
| Priority | Minor [ 4 ] | Major [ 3 ] |
| Fix Version/s | 10.4 [ 22408 ] |
| Status | Open [ 1 ] | In Progress [ 3 ] |
| Affects Version/s | 10.4.10 [ 23907 ] |
| Fix Version/s | 10.1 [ 16100 ] | |
| Fix Version/s | 10.2 [ 14601 ] | |
| Fix Version/s | 10.3 [ 22126 ] |
I downloaded a binary tarball, and it does look like @sbindir@ is being expanded to different paths when you compare the galera_recovery script and the mariadb.service unit file.
galera_recovery:
eval ./bin/mysqld $cmdline_args --user=$user --wsrep_recover \
|
--disable-log-error 2> "$log_file"
|
mariadb.service:
ExecStart=/usr/local/mysql/bin/mysqld $MYSQLD_OPTS $_WSREP_NEW_CLUSTER $_WSREP_START_POSITION
|
This difference in behavior seems to occur because the scripts/ directory has special CMake rules that change the paths for "standalone" installations:
# Really ugly, one script, "mysql_install_db", needs prefix set to ".",
|
# i.e. makes access relative the current directory. This matches
|
# the documentation, so better not change this.
|
|
|
IF(INSTALL_LAYOUT MATCHES "STANDALONE")
|
SET(prefix ".")
|
SET(bindir ${prefix}/${INSTALL_BINDIR})
|
SET(sbindir ${prefix}/${INSTALL_SBINDIR})
|
SET(scriptdir ${prefix}/${INSTALL_BINDIR})
|
SET(libexecdir ${prefix}/${INSTALL_SBINDIR})
|
SET(pkgdatadir ${prefix}/${INSTALL_MYSQLSHAREDIR})
|
SET(localstatedir ${prefix}/data)
|
ELSE()
|
SET(prefix "${CMAKE_INSTALL_PREFIX}")
|
SET(bindir ${INSTALL_BINDIRABS})
|
SET(sbindir ${INSTALL_SBINDIRABS})
|
SET(scriptdir ${INSTALL_BINDIRABS})
|
SET(libexecdir ${INSTALL_SBINDIRABS})
|
SET(pkgdatadir ${INSTALL_MYSQLSHAREDIRABS})
|
SET(localstatedir ${MYSQL_DATADIR})
|
ENDIF()
|
https://github.com/MariaDB/server/blob/mariadb-10.1.43/scripts/CMakeLists.txt#L204
| Priority | Major [ 3 ] | Critical [ 2 ] |
| Assignee | Julius Goryavsky [ sysprg ] | Jan Lindström [ jplindst ] |
| Status | In Progress [ 3 ] | In Review [ 10002 ] |
| Assignee | Jan Lindström [ jplindst ] | Julius Goryavsky [ sysprg ] |
| Status | In Review [ 10002 ] | Stalled [ 10000 ] |
| issue.field.resolutiondate | 2020-05-12 12:10:10.0 | 2020-05-12 12:10:10.483 |
| Fix Version/s | 10.1.44 [ 23912 ] | |
| 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 | Stalled [ 10000 ] | Closed [ 6 ] |
The bug was reported in 10.4.x, but Fix Version(s lists only 10.1.44. What exact 10.4.x version the fix is going into?
| Fix Version/s | 10.4.13 [ 24223 ] |
Corrected by adding the version number (10.4.13) to fix versions. Fixed for all branches starting from 10.1. Next, the patch was merged from 10.1 to all the main branches, sequentially, including 10.4: https://github.com/MariaDB/server/commit/c8e0c524af83149e77c88e9a6fd763221dea9277
Hi sysprg,
Next, the patch was merged from 10.1 to all the main branches, sequentially, including 10.4
So shouldn't "Fix Version(s)" also mention 10.2.32 and MariaDB 10.3.23?
Also, GitHub says that the commit that you linked is in MariaDB 10.1.45, but "Fix Version(s)" for this bug lists MariaDB 10.1.44. Is it also incorrect to have "MariaDB 10.1.44" in "Fix Version(s)" then?
I took a look at the source code, and it does look to me like MariaDB 10.1.44 still has the bug, while MariaDB 10.1.45 has the fix:
https://github.com/MariaDB/server/blob/mariadb-10.1.44/support-files/mariadb.service.in#L73
https://github.com/MariaDB/server/blob/mariadb-10.1.45/support-files/mariadb.service.in#L73
So the "Fix Version(s)" field for this bug should actually be "MariaDB 10.1.45, 10.2.32, MariaDB 10.3.23, MariaDB 10.4.13" and "MariaDB 10.1.44" should be completely removed from the field, right?
| Fix Version/s | 10.3.23 [ 24222 ] | |
| Fix Version/s | 10.2.32 [ 24221 ] | |
| Fix Version/s | 10.1.45 [ 23913 ] | |
| Fix Version/s | 10.1.44 [ 23912 ] |
GeoffMontee Thanks for the clarification, I corrected the list of versions - indeed, the correction is relevant only from 10.1.45 and it was necessary to specify other versions
| Workflow | MariaDB v3 [ 99989 ] | MariaDB v4 [ 156788 ] |
| Zendesk Related Tickets | 161052 |
The galera_recovery script refers to mysqld through the path defined by @sbindir@, which is expanded at compile time:
eval @sbindir@/mysqld $cmdline_args --user=$user --wsrep_recover \--disable-log-error 2> "$log_file"https://github.com/MariaDB/server/blob/mariadb-10.1.43/scripts/galera_recovery.sh#L71
The primary systemd unit file also refers to mysqld through the path defined by @sbindir@:
ExecStart=@sbindir@/mysqld $MYSQLD_OPTS $_WSREP_NEW_CLUSTER $_WSREP_START_POSITIONhttps://github.com/MariaDB/server/blob/mariadb-10.1.43/support-files/mariadb.service.in#L84
I'm not sure why the path causes issues in the galera_recovery script, but the same path apparently does not cause issues in the systemd unit file.