Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.1.16
-
Scientific Linux 7.2, using systemd
Description
We compile our own MariaDB packages, and all galera and wsrep files have been separated into a subpackage along with its dependencies and configuration files.
After upgrading from 10.1.14 to 10.1.16, mariadb server fails to start due to missing the galera_recovery script. From what I can gather in the systemd configuration, it could/should check for the existance of galera_recovery before attempting to run it.
As a workaround I could include the script in the server subpackage, but I am uncertain whether that would actually work since it might just error out due to other missing wsrep/galera files.
The cleanest way I think would be to only run the script if it exists, and otherwise assume galera is not activated. Possibly check for some other file(s) as well and return a warning if galera is present such that it can be activated but the recovery script is missing.
Attachments
Issue Links
- links to
We are using the following patch as a temporary workaround. It has the side-effect that it causes _WSREP_START_POSITION to be set even though galera_recovery did not exist and thus was not run. It is a bit ugly, but whether it can actually cause a real problem, I do not know.
--- old/support-files/mariadb.service.in 2016-07-14 03:10:31.000000000 +0200+++ new/support-files/mariadb.service.in 2016-08-11 10:19:18.421000000 +0200@@ -63,7 +63,7 @@# the script is not expected to return with a non-zero status.# It is always safe to unset _WSREP_START_POSITION environment variable.ExecStartPre=/bin/sh -c "systemctl unset-environment _WSREP_START_POSITION"-ExecStartPre=/bin/sh -c "VAR=`/usr/bin/galera_recovery`; [ $? -eq 0 ] && \+ExecStartPre=/bin/sh -c "[ -e /usr/bin/galera_recovery ] && VAR=`/usr/bin/galera_recovery` || exit 0; [ $? -eq 0 ] && \systemctl set-environment _WSREP_START_POSITION=$VAR || exit 1"# Needed to create system tables etc.