Comment 3 for bug 685809

I found the problem. The cause is high load on the test server causing the
mysqld server to take more than 14 seconds to start.

(This is not unexpected, as eg. innodb has to initialise all its log files and
table space, and the host is running 3+ busy virtual machines, so I/O can
easily be slow at times. It could also happen eg. if innodb would need to do
recovery; not something to be recommended during upgrade, but could
happen. Also if an existing config file with large innodb logs/tablespaces
exists, again initialisation could take a long time.)

The /etc/init.d/mysql script starts the server and waits for 14 seconds for it
to become available. If it does not within this timeout, it gives up with the
given error, causing install to fail.

I am considering two options for solving this:

1. Increase the timeout to much higher, maybe 60 or 120 seconds. Then after 14
seconds we could output a warning that mysql is slow to start, and that we are
still waiting 46 (/106/whatever) seconds for it to come up.

2. Keep the existing timeout by default, add an environment variable
STARTUP_TIMEOUT that the tests can set to get a higher timeout.

A disadvantage of (1) is that it is not uncommon for mysqld to fail to start
at all. Quite common for example is a mis-match of actual innodb log file size
vs. configured size. This would cause the user to sit and wait for 60/120
seconds before getting a reported failure.

Need to think about what to do, however I lean mostly towards (2) I think. It
seems quite rare in practise that mysqld would need more than 14 seconds to
start up.