CentOS 5 , and CentOS 6

Never used Jira, sorry about the code format above. This is what that should have looked like:

The MariaDB-Server RPM appears to contain a flawed method of determining mysql 'datadir' path.

This is in the post-install scriptlet packaged in the RPM for both the centos5 and centos6 versions, and both 64bit and 32bit packages.

Relevant part of the post-installation shell scriptlet:

mysql_dirs=(`/usr/sbin/mysqld --verbose --help 2>/dev/null|sed -ne 's/^(basedir|datadir)[[:space:]](.)$/\2/p'`)
basedir="${mysql_dirs[0]}"
datadir="${mysql_dirs[1]}"

1. datadir may be relative to a basedir!
   if expr $datadir : / > /dev/null; then
   mysql_datadir=$datadir
   else
   mysql_datadir=$basedir/$datadir
   fi

In my testing, the initial shell array, $mysql_dirs is empty when that command is run. Thus mysql_datadir="/"

This is dangerous because the subsequent use of the variable is:

chown -R mysql:mysql $mysql_datadir

On the centos6 server, moving /etc/my.cnf to /etc/my.cnf.TMP ahead of time, makes the initial population of $mysql_dirs[@] to be correct. (not sure why yet)

On the centos5 server it's the same deal, however, moving the my.cnf causes the array to populate, but it still produces incorrect path values:

mysql_dirs[0] => .
mysql_dirs[1] => /

I don't have a suggestion at the moment for how to fix, although I believe there must be a better way to find the mysql datadir than the current implementation.

I hope this is the right place to submit this bug. I marked it critical because chowning the entire filesystem mysql:mysql recursively is fairly catasthropic.

No worries, we can always fix the formatting. But just so you know, your guess about

was right, but it only works in the description, not in comments.

Hi Kevin,

Could you please attach my.cnf which causes the described problem?

Thanks.

Also, run, manually, "mysqld --help --verbose" and see the values of the datadir and basedir variables.

I figured a scenario when the whole story adds up and is still realistic.

The only way for this command
/usr/sbin/mysqld --verbose --help 2>/dev/null|sed -ne 's/^(basedir|datadir)[[:space:]](.)$/\2/p'

to return an EMPTY result is that /usr/sbin/mysqld fails to print help at all, otherwise there would have been something, even if it's only empty lines.
It could have been either because mysqld does not start (e.g. binary isn't compatible with the system), but in this case moving /etc/my.cnf wouldn't solve the problem; or because /etc/my.cnf contains something that doesn't allow mysqld to print help. I used character-set-server for my experiment, and it went pretty much as described. Yum installed the server, printed an error message about expr which is easy to miss (expr: syntax error), proceeded and changed ownership of the entire system.

For the test I had set character-set-server to an invalid value on purpose, but it could have been unintentional: character sets do change, and a previous server might have had one which the new server doesn't. So I think it cannot be considered just misconfiguration.

I suppose a simple way to fix this is to check that the command above returned results; if it didn't, something definitely went wrong, and installation should be aborted.

Reproducible on MariaDB 5.5.28a and 10.0.0.
Not reproducible on MySQL 5.5.29, MariaDB 5.3.11 and MariaDB 5.2.13 – they all notice the invalid value, but don't change ownership of the root dir.

Hello,

You are quick to respond. I appreciate it. It appears you are correct. When I did my cursory testing I left in place the redirection of STDERR to the bitbucket, so I didn't notice this:

root@server # /usr/sbin/mysqld --verbose --help
130120 12:16:37 [Warning] '-log_slow_queries' is deprecated and will be removed in a future release. Please use ''slow_query_log'/'-slow_query_log_file'' instead.
Unknown suffix 'A' used for variable 'concurrent-insert' (value 'ALWAYS')
130120 12:16:37 [ERROR] /usr/sbin/mysqld: Error while setting value 'ALWAYS' to 'concurrent-insert'
130120 12:16:37 [ERROR] Aborting

So obviously it sends nothing to stdout, and simply produces an error message if my.cnf has errant values ( or likely a number of other scenarios could cause this )

I agree on aborting installation on failure to produce results to STDOUT from the mysqld --verbose --help command. Perhaps also, an additional paranoid sanity check on the value of mysql_dir . If it's "/", abort.

Here's why: On this centos5 box, observe the output when my.cnf is moved:

mv /etc/my.cnf /etc/my.cnf.tmp
/usr/sbin/mysqld --verbose --help
[...SNIP...]
basedir /
[...SNIP...]
datadir .

So perhaps incidentally, we would end up with the same result I believe. Not sure if it would be chown -R mysql:mysql "/" or chown -R mysql:mysql "/.", but I believe the results would be the same.

Note that the my.cnf on this centos5 machine I simply copied from the centos6 machine for testing. It has all kinds of errant values because it was for a mysql running innodb tables, and probably different versions of mysql, etc..

If it would help, I can produce the output of whatever you would like from both machines, but I can't do that now. I will have access to both of them later. If you provide a list of everything you would like me to run, I can. I'm not sure if it matters, but this is a cpanel box, as is the centos6 one. Let me know what you need from me.

Actually, I will not be able to run commands on the original centos6 machine. But I can run anything on the centos5 box.

Regardless, let me know what, if anything I can do to help. Thanks again for looking into this!

The story with centos5 is different. After you move out the problematic my.cnf, the initial problem is gone, and there are apparently other my.cnf files which affect the outcome.

Also, there is some contradiction. Earlier you said that you were getting

mysql_dirs[0] => .
mysql_dirs[1] => /

Which means mysqld returned basedir . and datadir as /
In the last comment, it's the other way round: basedir / and datadir .

The first pair of values is completely weird, I can't think of another way to get it but set them manually in the config file.
For the second pair, I can imagine that some build could have produced it and that's why you have them in the config.

Then, if the values were set manually, I don't think there is much we can – or even should – do. After all, you do it as root, so you get what you want. If the values were produced automatically, we should find out how it happened at the first place.

So, for starters, please check the default locations of my.cnf on that box. One of them probably has a file where these values set explicitly.
I usually run mysql --help | grep cnf to find the default locations, but please note that the files can be innocent at the first glance, but contain includes.

If you find the "guilty" file, and you suspect it was generated automatically, please attach it. Or better still, please create another bug report and attach it there, since the problem is different.

Thanks.

Adding a simple test to check that both values are not empty or only containing a . or a / would still be safer even if it should never happen in normal usecases.

Also, this error is strange and again makes the story unclear

Unknown suffix 'A' used for variable 'concurrent-insert' (value 'ALWAYS')
130120 12:16:37 [ERROR] /usr/sbin/mysqld: Error while setting value 'ALWAYS' to 'concurrent-insert'

Could you please double-check which version you are trying to install, and which version ends up in /usr/sbin/mysqld ?
/usr/sbin/mysqld --version

It's a 5.1-based version error, 5.5.28 should have no problem with ALWAYS.

Elena,

You are correct on the contradiction. I was trying to make things simple when i posted:

mysql_dirs[0] => .
mysql_dirs[1] => /

IS INCORRECT / Inverted. My fault. Sorry, I was trying to make things clear, and I switched the two. Here is the command and output:

root@server # /usr/sbin/mysqld --verbose --help | egrep '(basedir|datadir)'
130120 20:42:30 [ERROR] Fatal error: Please read "Security" section of the manual to find out how to run mysqld as root!

130120 20:42:30 [ERROR] Aborting

-b, --basedir=name Path to installation directory. All paths are usually
-h, --datadir=name Path to the database root.
basedir /
datadir .

So basedir == /
and datadir == .

I'm sorry for the confusion. Please tell me exactly what to run on this centos5 machine and I will provide exact output.

-kevin

I suggest

• to remove that bad my.cnf from your centos5 machine;
• then run mysql --help | grep cnf
  (it will print default locations of cnf files on the machine);
• then, check each location one by one and see if there is the file; if there is, check if it contains basedir and/or datadir;
  (also check if the file contains include, and if so, go through the included files in the same way);
• then let us know if you found any basedir or datadir values.

Thanks.

root@server # ls -la /etc/my.cnf.*
rw-rr- 1 root root 80 Dec 7 2011 /etc/my.cnf.hold
rw-rr- 1 root root 1468 Jan 17 09:34 /etc/my.cnf.tmp
root@server #

root@server # mysql --help | grep cnf
order of preference, my.cnf, $MYSQL_TCP_PORT,
/etc/mysql/my.cnf /etc/my.cnf ~/.my.cnf
root@server # cat /etc/mysql/my.cnf
cat: /etc/mysql/my.cnf: No such file or directory
root@server # cat /etc/my.cnf
cat: /etc/my.cnf: No such file or directory
root@server # cat ~/.my.cnf
[client]
pass="REDACTED"
user=root

Did you have a chance to check the version of /usr/sbin/mysqld as mentioned earlier?
/usr/sbin/mysqld --version

Elena,

root@server # /usr/sbin/mysqld --version
/usr/sbin/mysqld Ver 5.1.66-cll for unknown-linux-gnu on x86_64 (MySQL Community Server (GPL))

Hm. I've somehow let myself get confused about the datadir / basedir issue, which appears to have nothing to do with the RPM. Sorry for causing confusion about the 2nd issue.

If so, it would appear there is only one issue: Checking if:

/usr/sbin/mysqld --verbose --help

returns error and if so abort installation. I believe you already addressed this, so I suppose this can be wrapped up. Thanks

One root of the problem is that the script is using mysqld --help --verbose to get the options. The reason is that this may fail if there are some wrong commands/variables in my.cnf

A better way is to use 'my_print_defaults mysqld mariadb server client-server'.

This is what scripts like mysqld_safe uses.

We could of course also add a check that the values are reasonable.

• BASEDIR/libexec/mysqld or BASEDIR/sbin/mysqld should exists
• DATADIR should not exists or the directory DATADIR/mysql should exists

elenst so shall I push that?
http://lists.askmonty.org/pipermail/commits/2013-March/004372.html

Yes, please. I'll test an RPM from buildbot when it's baked.

(I tried to imitate buildbot by patching manually and building my own RPM on CentOS 5, same way buildbot does, using "cmake . -DBUILD_CONFIG=mysql_release -DRPM=centos5", but it turned out not that easy as it requires a higher version of cmake than CentOS 5 has)

Checked a manual RPM build on Fedora 17 64-bit, made from 5.5-serg revno 3685, source package prepared by buildbot (could not use an RPM baked by buildbot since it's not in archives [yet]).

1) Installation of the package with broken my.cnf didn't cause the previous disaster. It still fails, of course (DB initialization doesn't work since mysqld cannot start), but the problem is fixable after installation by re-running mysql_install_db manually.
2) Installation of the package in normal conditions went okay.
3) Installation of the package with non-default basedir in my.cnf doesn't go too well (DB initialization doesn't work), but it's the same on old and new packages, so it's irrelevant. The problem is fixable the same way as in (1).

One thing that comes to mind with these tests is that it's probably not right when yum installation exits with code 0 even although something went very wrong on the way; so, it's easy to miss the problem, and then it's very confusing when the fresh MariaDB installation turns out to be broken.
But I'm not sure if it depends on us, and in any case it's out of scope of this bug.

pushed in 5.5