Startup fails due to hard-coded timeout in init script

10sec here should be only for server pid to show up not for the full server to start, when pid show's up then it waits unlimited time for server to become pingable.
Need to check that part maybe there's something wrong with it.

@Tomislav based on your comment, I think the 10sec loop should look like this:

# wait 10sec before start checking if pid file created or server is dead
if [ $dead_check_counter -lt 10 ]; then
    dead_check_counter=$(( dead_check_counter + 1 ))
else
    if mysqld_status check_alive nowarn; then break; fi
fi

i.e. the else clause should run "mysqld_status check_alive" instead of "mysqld_status check_dead". This will cause it to loop forever until the server responds to ping.

Also when you mentioned the server pid, are you referring to mysqld_status watching for the pid file? If so, I see a couple of problems with this:

- I don't see the pid file showing up until after the server has started (specifically, until after the log shows "ready for connections"), which in our case means the pid file doesn't exist until after the 10sec loop is finished and the init script has exited.

- mysqld_get_param doesn't know what our pid file is unless I specify it in my.cnf, and even then, I need to specify it as pid-file and not pid_file (i.e. hyphen and not underscore). If I don't specify it in my.cnf at all, it doesn't show up in mysqld --print-defaults. If I specify it as pid_file then mysqld_get_param still doesn't find an option called pid-file. In both cases mysqld_status doesn't end up knowing the name of the pid file.

I agree with the reporter this is a bug. I saw many cases when MySQL Server does not create PID in 10 seconds. This parameter should be configurable.

See also old MySQL bug, fixed long time ago: https://bugs.mysql.com/bug.php?id=25341 Maybe time to port this fix into Percona Server too?

This bug affects more on the install and upgrade process than starting up the database routinely, because if you start up the database manually, you can always wait and check the log file after it reports startup "failure", however during the upgrade, after the startup failure, the post configuration process also fails and package state is in limbo. Next time when you try to run the package command, it will try to re-run the command to finish the unfinished business (at least this is the case on Ubuntu).

The workaround is to have a version of modified /etc/init.d/mysql in place, and run the installation command with the option NOT to replace the configuration file. It is like below on Ubuntu:

# export DEBIAN_FRONTEND=noninteractive
# apt-get -y -o Dpkg::Options::="--force-confold" install percona-server-server-5.6

I spent a lot of time figured out all these, hope this helps.

https://github.com/percona/percona-server/pull/219
https://github.com/percona/percona-server/pull/220

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PS-1617