Uploaded image for project: 'MariaDB Server'
  1. MariaDB Server
  2. MDEV-20676

systemd script not working

Details

    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

          Ascending order - Click to sort in descending order
          GeoffMontee Geoff Montee (Inactive) added a comment -

          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_POSITION

          https://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.

          GeoffMontee Geoff Montee (Inactive) added a comment - 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_POSITION https://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.
          GeoffMontee Geoff Montee (Inactive) added a comment - - edited

          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

          GeoffMontee Geoff Montee (Inactive) added a comment - - edited 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
          sysprg Julius Goryavsky added a comment -

          Fixed, https://github.com/MariaDB/server/commit/cbf00b625a831a306fcfa450b76f580d962c75db

          sysprg Julius Goryavsky added a comment - Fixed, https://github.com/MariaDB/server/commit/cbf00b625a831a306fcfa450b76f580d962c75db
          jplindst Jan Lindström (Inactive) added a comment -

          ok to push

          jplindst Jan Lindström (Inactive) added a comment - ok to push
          sysprg Julius Goryavsky added a comment -

          Fix here: https://github.com/MariaDB/server/commit/cbf00b625a831a306fcfa450b76f580d962c75db

          sysprg Julius Goryavsky added a comment - Fix here: https://github.com/MariaDB/server/commit/cbf00b625a831a306fcfa450b76f580d962c75db
          valerii Valerii Kravchuk added a comment -

          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?

          valerii Valerii Kravchuk added a comment - 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?
          sysprg Julius Goryavsky added a comment -

          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

          sysprg Julius Goryavsky added a comment - 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
          GeoffMontee Geoff Montee (Inactive) added a comment -

          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?

          GeoffMontee Geoff Montee (Inactive) added a comment - 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?
          sysprg Julius Goryavsky added a comment -

          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

          sysprg Julius Goryavsky added a comment - 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

          People

            sysprg Julius Goryavsky
            kurschies Benjamin Kurschies
            Votes:
            1 Vote for this issue
            Watchers:
            9 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Git Integration

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