Red Hat Bugzilla – Bug 168121
mysqld init script fails with NFS-hosted storage
Last modified: 2013-07-02 23:06:52 EDT
From Bugzilla Helper:
User-Agent: Opera/8.02 (X11; Linux i686; U; en)
Description of problem:
In /etc/my.conf, I have datadir set to a directory that resides on an NFS mount.
The directory and its contents are owned by the mysql user (present on both
client and server), but the directory containing datadir is owned by root. I
have root squashing enabled, so niether root nor the mysql user on the NFS
client machine (where I am running the MySQL server) would be unable to create
the directory named by datadir or to change its permissions. No such operation
is necessary, since the directory already exists and has its permissions set
Running /etc/init.d/mysqld start results in unconditional failure, however,
because there is an unconditional chown and chmod on datadir after the check to
see that datadir exists (lines 68 and 69).
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Set datadir in /etc/my.cnf to a root-squashed NFS-hosted directory
2.Create datadir manually and give it the appropriate permissions
3.run /etc/init.d/mysqld start
Actual Results: /etc/init.d/mysqld start fails.
Expected Results: /etc/init.d/mysqld start succedes.
The chmod and chown may be desirable for idiot-proofing, but I think it more
valuable to avoid breaking a situation such as mine. As a quick fix, I simply
commented them out. Perhaps the correct fix would be as follows:
1. A non-recursive chown / chmod on $datadir only if the permissions are not set
2. A recursive chmod on $datadir/*
Since the script doesn't actually check whether those operations succeed, I
don't think you've correctly identified the problem. I'd guess that what's
really failing is the attempt to run mysql_install_db as root (line 61).
It's possible that su'ing to mysql to run mysql_install_db would work, but I'm
hesitant to change that because I'm not sure what sort of side effects it would
have for other people. I'd suggest that you run mysql_install_db manually
instead of just creating the directory manually.
Whoops, you're quite right. I uncommented the lines and it still worked. So I
tried again on a different machine that did not previously have the mysql-server
package installed. Once again I got failure, with the following message left in
050912 16:58:17 mysqld started
050912 16:58:17 [Warning] Can't create test file /clair/www/mysql/london.lower-
/usr/libexec/mysqld: Can't change dir to '/clair/www/mysql/' (Errcode: 13)
050912 16:58:17 [ERROR] Aborting
050912 16:58:17 [Note] /usr/libexec/mysqld: Shutdown complete
050912 16:58:17 mysqld ended
I was unable to determine the cause of this. Restarting nscd didn't help.
Nothing else in any system logs. And then about 14min later it began to work
out of the blue, and now continues to work. My guess is that the same thing
happened on the first machine, and I just happened to have commented out those
lines just before it did.
On my machines, I've got a combination of LDAP, NFS, AFS, and some Kerberos here
and there, and this wouldn't be the first odd hiccup that's come up. As long as
the init script contniues to work as it has been, I'm willing to chalk all this
up to some idiosyncrasy in my systems' configuration.
Well, the theory I had doesn't explain any transient failure, only permanent
ones, so now I have no idea what to do. I suspect you are right that there's
some contributing factor in your environment that we don't recognize. There
isn't going to be much I can do about it unless you can come up with more
information to nail down what's really happening.
Yeah, I suppose this should be closed as WORKSFORME. If it ever stops working,
I'll at least have a better opportunity to try to pinpoint the necessary
conditions for failure.
Thanks for your time.
OK, I'll mark it closed for now. Feel free to reopen the bug report if you can
get more info on it.