Red Hat Bugzilla – Bug 82152
/etc/rc.d/init.d/mysqld with custom my.cnf error
Last modified: 2006-02-21 13:51:14 EST
Description of problem:
I have a custom my.cnf where I relocate the datadir to /mysql/databases
When starting the mysql server it says that I need to create the mysql
database. But it's there and has been there for ages. It isn't in the default
location /var/lib/mysql. Although it gives this warning the mysql starts up.
But when I wan't to restart it it doesn't. I suspect it searches its pid file in
the wrong place.
Version-Release number of selected component (if applicable):
Note: I use mysql-server-3.23.54a-4 on RH 8.0 and mysql-server-3.23.54a-3.72 on
I also have a custom my.cnf file, where I specify a different datadir.
The problem is that the init script for mysql has datadir hard-coded into it, so
at the point where it checks for the existence of the 'mysql' subdirectory, it
hasn't read the my.cnf file yet. Naturally, I have the option of *modifying* the
init script, but since the file is not marked as a %config file, it will be
ruthlessly overwritten next time I upgrade the package.
Would it be possible to do one of the following:
1) make the init script take /etc/my.cnf into consideration for variable definitions
2) create a separate config file (such as /etc/sysconfig/mysqld) that would
duplicate some of the data stored in /etc/my.cnf (like the datadir location) and
one that would be taken into consideration for variable definitions
3) make /etc/rc.d/init.d/mysqld a config file
I think option 1) would be most desirable here -- it would require more work
than 3), but be as complete as 2) without duplication of configuration data
This is a duplicate of 76051. In that bug report Henning provides
a solution to the problem. I've marked 76051 as an enhancement as
there is a work around available. As soon as we finish clearing
the backlog and shipping associated errata, we'll investigate
Both Peter and Henning make a good point about not wanting to
alter the mysqld script as it's not marked as %config.
*** This bug has been marked as a duplicate of 76051 ***
Changed to 'CLOSED' state since 'RESOLVED' has been deprecated.