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 appropriately. 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): mysql-server-2.1.12-2.FC4.1 How reproducible: Always 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. Additional info: 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 correctly. 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 /var/log/mysqld.log: 050912 16:58:17 mysqld started 050912 16:58:17 [Warning] Can't create test file /clair/www/mysql/london.lower- test /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.