Problems with multiple versions (4.0, 4.1) with mysqld_safe

I am running mysql-standard-4.0.20-pc-linux-i686 and mysql-standard-4.1.12-pc-linux-gnu-i686 on the same machine, installed binaries.
I had a heck of a time running both of these versions at once. And not for the typical reasons: port collision, sock file, etc… I have that all figured out, I should be able to run two versions of MySQL on the same machine. I am running 4.0 out of /usr/local/mysql and trying to run 4.1 out of /usr/local/mysql-4.1 and cannot get it working for the life of my, using the mysqld_safe script.

I kept getting this error when I would start MySQL 4.1:

050707 14:46:41 Fatal error: Can’t open privilege tables: File ‘/usr/local/mysql-4.1/share/mysql/charsets/?.conf’ not found (Errcode: 2)
050707 14:46:41 Aborting
050707 14:46:41 InnoDB: Starting shutdown…
050707 14:46:43 InnoDB: Shutdown completed
050707 14:46:43 /usr/local/mysql/bin/mysqld: Shutdown complete

Notice: /usr/local/mysql/bin/mysqld (that’s not what my basedir is!, it’s “/usr/local/mysql-4.1″

Initially I had mysql 4.0 running at /usr/local/mysql/, and I thought I could get around the problem it by moving /usr/local/mysql to /usr/local/mysql-4.0, so that I don’t have a /usr/local/mysql directory, because seemed to be something in mysql that expected stuff to live at /usr/local/mysql, and I thought if that dir didnt’ exist, it may try to use my defined basedir instead. This philosophy failed brutally, I went around in circles and all I did was make my 4.0 instance stop working also.

Turns out, the problem is with mysqld_safe.

I was starting my 4.1 server server like this:
/usr/local/mysql-4.1/bin/mysqld_safe –defaults-file=/etc/my-4.1-1.cnf –max-connect-errors=10000 –user=mysql

and my /etc/my-4.1-1.cnf file looks like this:

pid_file = /var/lib/mysql-4.1/1/
datadir = /var/lib/mysql-4.1/1/data
port = 3406
socket = /tmp/mysql-4.1-1.sock
key_buffer = 16M
max_allowed_packet = 16M
table_cache = 64
sort_buffer_size = 512K
net_buffer_length = 8K
read_buffer_size = 256K
read_rnd_buffer_size = 512K
myisam_sort_buffer_size = 8M
server-id = 1
innodb_data_home_dir = /var/lib/mysql-4.1/1/tables
innodb_data_file_path = ibdata1:10M:autoextend
innodb_log_group_home_dir = /var/lib/mysql-4.1/1/logs
innodb_log_arch_dir = /var/lib/mysql-4.1/1/logs
innodb_buffer_pool_size = 16M
innodb_additional_mem_pool_size = 2M
innodb_log_file_size = 5M
innodb_log_buffer_size = 8M
innodb_flush_log_at_trx_commit = 1
innodb_lock_wait_timeout = 50

All of my directories are in place an user and group owned by mysql, I followed the setup procedure in the INSTALL-BINARY very closely, and my workaround proves that there is nothing wrong with my installation, choice of directories, permissions, etc.

My workaround is: using the same /etc/my-4.1-1.cnf file as above, start my server with mysqld instead of mysqld_safe, like this:
/usr/local/mysql-4.1/bin/mysqld –defaults-file=/etc/my-4.1-1.cnf –max-connect-errors=10000 –user=mysql > /var/lib/mysql-4.1/1/mysql-4.1-1.err 2>&1 &

and now it works just fine.

CONCLUSION: something is wrong with mysqld_safe that doesn’t allow it to work when the basedir is not /usr/local/mysql — can anybody find the problem and post a fix to mysqld_safe? It should be picking up default values from the defaults-file! Maybe it does when the defaults file is /etc/my.cnf ???? But I am using /etc/my.cnf for MySQL 4.0, so don’t tell me to make my conf file /etc/my.cnf — can’t (unless I change the conf file for the MySQL 4.0 instance – in which case I have the same problem with that file). My workaround is: don’t use mysqld_safe. My point is: what’s wrong with it, and can somebody fix it?

I have posted this as a bug to the MySQL website, it’ll be interesting to see what they say about it:


New experiment shows this bug is not easily reproduced:

I moved to a new machine that does not have MySQL on it at all, then did this:

cd /usr/local
tar -xzf src/mysql-standard-4.1.12-pc-linux-gnu-i686.tar.gz
ln -s mysql-standard-4.1.12-pc-linux-gnu-i686 mysql-41
cd mysql-41
/usr/sbin/groupadd mysql
/usr/sbin/useradd -g mysql mysql
scripts/mysql_install_db –user=mysql
chown -R root .
chown -R mysql data
chgrp -R mysql .

echo ‘[mysqld]
server-id = 1′ > /etc/my-41.cnf
cd /

This command:
/usr/local/mysql-41/bin/mysqld_safe –defaults-file=/etc/my-41.cnf –user=mysql &

/usr/local/mysql-41/bin/mysqld_safe: line 1: my_print_defaults: command not
/usr/local/mysql-41/bin/mysqld_safe: line 1: my_print_defaults: command not
The file /usr/local/mysql/bin/mysqld doesn’t exist or is not executable
Please do a cd to the mysql installation directory and restart
this script from there as follows:
See for more

[1]+ Exit 1 /usr/local/mysql-41/bin/mysqld_safe
–defaults-file=/etc/my-41.cnf –user=mysql

(Note: No error log was created.)
(Also note, this is not a bug, and not really relevant to the problem at hand, but worth mentioning. Also, it’s documented here:

This command:
cd /usr/local/mysql-41
bin/mysqld_safe –defaults-file=/etc/my-41.cnf –user=mysql &

Starting mysqld daemon with databases from /usr/local/mysql-41/data

So, it works fine, as long as you cd to the /usr/local/mysql-41/ directory
first, then call bin/mysqld_safe. Works for me, experiment shows that the bug I encountered on my first machine is isolated to that machine.

So, I looked at my first machine to find out why it was so broken there and
discovered this:

rpm -qa | grep -i mysql


Bunch of RPMs that I didn’t know where there and are not in use. So, I did a:
rpm -e MySQL-client-4.0.9-0 MySQL-devel-4.0.9-0 MySQL-Max-4.0.9-0
MySQL-shared-3.23.56-1.0.23 MySQL-4.0.9-0

Then I ran:
cd /usr/local/mysql-4.1
bin/mysqld_safe –defaults-file=/etc/my-4.1-1.cnf –max-connect-errors=10000
–user=mysql &

… and now it works fine! So, the problem has something to do with the
existence of one of those older RPMs.

Conclusion: there is still a bug with mysqld_safe, but it’s pretty hard to setup the conditions to cause it. You’ll need one or more of the above RPMs installed, and MySQL-4.1 in a non-standard location.

Comments are closed.