MySQL Bugs: #17972: mysql_install_db hangs on starting mysqld

Bug #17972	mysql_install_db hangs on starting mysqld
Submitted:	6 Mar 2006 15:49	Modified:	25 May 2006 14:28
Reporter:	Frank Bellavance	Email Updates:
Status:	No Feedback	Impact on me:	None
Category:	MySQL Server	Severity:	S2 (Serious)
Version:	5.0.18	OS:	Linux (RedHat Linux ES 4 update 2)
Assigned to:		CPU Architecture:	Any

Description:
I am installing using the source tar balls. 

configure: ./configure --prefix=/u02/mysql/dev --localstatedir=/u03/mysql/dev

make and make install go without any issue. 

Running mysql_install_db as follow

./mysql_install_db --user=mydev

User mydev exists and as the rights in /u02 and /u03 

When running the script, it will hard freze with the following text on display. The only way to end the script is to kill the process for it and mysqld

Installing all prepared tables
060306 12:00:46 [Warning] Can't open and lock time zone table: Table 'mysql.time_zone_leap_second' doesn't exist trying to live without them
060306 12:00:46 [Note] /u02/mysql/dev/libexec/mysqld: ready for connections.
Version: '5.0.18'  socket: '--bootstrap'  port: 3306  Source distribution

Adding & at the end of the line calling mysqld allowed to go further, but the tables are never created, leaving the install unusable. The .sql file found was a filler to satisfy dependency with no active code in it. 

How to repeat:
Compiling with the provided options always reproduce this issue on the same server. 

Suggested fix:
No fix sujested. Trying to get this working.

I found a solution using the binary distribution. 
When using the binary distribution, I had the exact same issue. Using the configure script would also cause issues. 

Editing the configure script to change ./scripts/mysql_install_db --no-defaults to 
./scripts/mysql_install_db --no-defaults --basedir=/[BASE_BIN_DIR] --datadir=[BASE_DATA_DIR] --log-error=[FUll_PATH_TO_LOG_FILE] --log-warnings --safe-mode --user=[MYSQL_USER] 

allowed the configure script to run properly.

Thank you for a problem report. Is it a fresh installation or you installed over previous version? Have you tried to build 5.0.19 that way?

I build with ./configure --prefix=/unusual_location 

(but without --localstatedir=...) several times per day usually and never saw any problem similar to those you described...

This was a "fresh" install in the sence that it wasn't on top of any other existing mysql install.

I had tried using only the --prefix=/unusual_location  option only, but had the same results. 

The default locations would still never get picked up by the generated configuration file. 

What I ended up doing as a workaround is specify all the paths in my start script. 

mysqld --basedir=/u02/mysql/[INSTANCE] --datadir=/u03/mysql/[INSTANCE] --log-error=/u03/mysql/[INSTANCE]/error.log --log-warnings --safe-mode --user=my[INSTANCE] --language=/u02/mysql/[INSTANCE]/share/mysql/english/ --socket=/u02/mysql/[INSTANCE]/mysql.sock

where [INSTANCE] is for the particular instance I am working on (say prod, dev, etc)

This allowed me to start mysql and it appears to have autogenerated the innitial db.

Correction to my prevoius entry. 
I guess it's still too early. When I said "it still wouldn't pick up the right location", I ment that the configuration script that was being run post install to innitiate the database would hang. 

What I found somewhat strange is that running with the above command line without running the post install configuration script generated the innitial database. This was confusing to me as it did not behave as I would have expected from the documentation.

Please, try to repeat with a newer version, 5.0.20a, and inform about the results.

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".