Details
-
Bug
-
Status: Closed (View Workflow)
-
Minor
-
Resolution: Fixed
-
5.5.29-galera
-
None
-
centos 6.4 amd64
Description
Start it from command:
/usr/bin/mysqld_safe --datadir=/var/lib/mysql --socket=/var/lib/mysql/mysql.sock --pid-file=/var/run/mysqld/mysqld.pid --basedir=/usr --user=mysql --log-error=/var/log/mysqld.log
|
And it will NOT never create sub process with mysqld , the status is shown as below:
root 13648 0.0 0.1 122240 4784 ? S 13:18 0:00 /usr/bin/python /usr/bin/pidproxy /var/run/mysqld/mysqld.pid /usr/bin/mysqld_safe --datadir=/var/lib/my
|
root 13649 0.0 0.0 108328 1544 ? S 13:18 0:00 /bin/sh /usr/bin/mysqld_safe --datadir=/var/lib/mysql --socket=/var/lib/mysql/mysql.sock --pid-file=/va
|
root 13921 0.0 0.0 103248 848 ? S 13:18 0:00 grep WSREP: Recovered position:
|
HOW TO FIX IT:
in /usr/bin/mysqld_safe (MariaDB-Galera-server-5.5.29-1.x86_64.rpm)
line 220:
[ "$EUID" = "0" ] && chown $user $wr_logfile
|
to fix it:
[ "$EUID" == "0" ] && chown $user $wr_logfile
|
Attachments
Activity
It turns out that the '=' comparison in dash also works correctly, the problem is that EUID is not defined in dash, hence the comparison with 0 is always false. This problem has been fixed in the current tree by defining a local euid as
euid=$(id -u)
and using it further in the comparison. It works both in dash and bash.
But the comparison is still '=', so the question above about your shell version (which understands '==' but not '=') becomes even more important.
Here are some test outputs:
[root@linux_dev_193 ~]# ls -lh /bin/sh
|
lrwxrwxrwx. 1 root root 4 6月 20 11:46 /bin/sh -> bash
|
[root@linux_dev_193 ~]# rpm -qa | grep bash
|
bash-4.1.2-14.el6.x86_64
|
|
|
[root@linux_dev_193 ~]# cat > 1.sh << EOF
|
> #!/bin/sh
|
>
|
> [ "$EUID" = "0" ] && echo "My EUID with =: $EUID"
|
> [ "$EUID" == "0" ] && echo "My EUID with ==: $EUID"
|
> EOF
|
[root@linux_dev_193 ~]# chmod +x 1.sh
|
[root@linux_dev_193 ~]# ./1.sh
|
My EUID with =: 0
|
My EUID with ==: 0
|
And this is my fault, I think it's a supervisor bug, or weird behavior of 'mktemp', see following code:
wr_logfile=$(mktemp)
|
[ "$EUID" = "0" ] && chown $user $wr_logfile
|
chmod 600 $wr_logfile
|
log_notice "WSREP: Running position recovery with --log_error=$wr_logfile"
|
$mysqld_cmd --log_error=$wr_logfile --wsrep-recover
|
rp=$(grep "WSREP: Recovered position:" $wr_logfile)
|
if wr_logfile is empty, and the 'grep' command will hang everything, but in normal shell, mktemp can NOT failed, so it's weird
so, for safety:
wr_logfile=`mktemp`
|
[ -f $wr_logfile ] || return 0
|
[ "$EUID" == "0" ] && chown $user $wr_logfile
|
chmod 600 $wr_logfile
|
log_notice "WSREP: Running position recovery with --log_error=$wr_logfile"
|
$mysqld_cmd --log_error=$wr_logfile --wsrep-recover
|
rp=$(grep "WSREP: Recovered position:" $wr_logfile)
|
Hi Seppo,
See the suggestion above about making wsrep-related logic in mysqld_safe.sh slightly safer.
Hi,
I agree there is a potential problem, but I'm not sure about your solution.
You put CentOS 6.4 in the environment field. What does your /bin/sh point at?
In my (more or less default) installation of CentOS 6.4 it points at bash, of version 4.1.2, which seems to be equally happy about either "=" or "==".
At the same time, on Ubuntu 12.04 /bin/sh points at dash; and it accepts "=", although it doesn't work correctly (hence the problem), but with "==" it complains about a syntax error.
So,
./1.sh
#!/bin/sh
[ "$EUID" = "0" ] && echo "My EUID with =: $EUID"
[ "$EUID" == "0" ] && echo "My EUID with ==: $EUID"
make it executable and execute twice, first time as a normal non-root user, and then under sudo, and paste the output.
Thanks.