ClusterLabs / ClusterLabs/resource-agents
Galera: mysql can't write into the mktemp created file
- Dominant language
- Shell
- Stars
- 519
- Forks
- 608
- Avg merge
- 6d 1h
- Merged PRs (30d)
- 7
Description
Hello all!
The galera resource agent has a problem determining the last cluster commit id because the mysql can't write to the temporary created file using mktemp.
For example:
local tmp=$(mktemp) is creating the temp file with root u+rw:
`-rw------- 1 root root 0 Feb 28 13:21 tmp.Q5LAsdR8EE`
Now the mysqld_safe process, which is usually running under other user like "mysql" can't write it's log in this file!
Not sure if thats a normal issue on all distris but its a problem on our centos 6 machine.
This is my fix for that issue using the current master:
~~~~
--- galera.orig 2017-02-28 13:18:39.274026052 +0100
+++ galera 2017-02-28 13:18:46.530401104 +0100
@@ -519,7 +519,7 @@
ocf_log info "attempting to detect last commit version by reading ${OCF_RESKEY_datadir}/grastate.dat"
last_commit="$(cat ${OCF_RESKEY_datadir}/grastate.dat | sed -n 's/^seqno.\s*\(.*\)\s*$/\1/p')"
if [ -z "$last_commit" ] || [ "$last_commit" = "-1" ]; then
- local tmp=$(mktemp)
+ local tmp=$(sudo -u $OCF_RESKEY_user mktemp)
# if we pass here because grastate.dat doesn't exist,
# try not to bootstrap from this node if possible
~~~~
Contributor guide
No contributing guide indexed for this repository
Research direction
Start in the Galera resource agent around the mktemp call used when grastate.dat has no usable last commit, and review how mysqld_safe runs under OCF_RESKEY_user. Reproduce the permission failure on the reported CentOS 6 setup, then verify that the temporary file can be written by the MySQL user and last-commit detection completes successfully.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- mysql, shell
- Domain
- databases
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100