Bug 168121 - mysqld init script fails with NFS-hosted storage
Summary: mysqld init script fails with NFS-hosted storage
Keywords:
Status: CLOSED CANTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: mysql
Version: 4
Hardware: i386
OS: Linux
medium
low
Target Milestone: ---
Assignee: Tom Lane
QA Contact: David Lawrence
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-09-12 17:55 UTC by Bryan Kisiel
Modified: 2013-07-03 03:06 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2005-09-13 17:27:58 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Bryan Kisiel 2005-09-12 17:55:22 UTC
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/*

Comment 1 Tom Lane 2005-09-12 20:51:31 UTC
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.

Comment 2 Bryan Kisiel 2005-09-12 21:25:46 UTC
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.

Comment 3 Tom Lane 2005-09-12 23:02:55 UTC
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.

Comment 4 Bryan Kisiel 2005-09-13 16:16:19 UTC
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.

Comment 5 Tom Lane 2005-09-13 17:27:58 UTC
OK, I'll mark it closed for now.  Feel free to reopen the bug report if you can
get more info on it.


Note You need to log in before you can comment on or make changes to this bug.