Comments on: The MySQL init-script mess

By: Xaprb

Xaprb — Sun, 30 Sep 2012 12:30:24 +0000

Sinisa,

what is the shortcoming of using kill instead of mysqladmin to shut down the server? I’ve always preferred kill, because it succeeds in more cases. See Eric’s blog post here for more details: http://ebergen.net/wordpress/2012/09/29/shutting-down-with-mysqld-mysqladmin-sigterm-or-sigkill/

By: Xaprb

Xaprb — Mon, 20 Aug 2012 20:41:02 +0000

As far as detecting whether the server has started, off the top of my head I’d do something like this: fork off the mysqld process, remember its PID, then go into a loop once a second. While the PID exists, check if you can connect to the server. If not, check the tail of its log file and see what is happening. It is likely to be performing recovery. It is also very possible that it’s in a loop trying to access the InnoDB files which another instance has locked. If that’s the case it should bail out and alert the user. But in the “good” case it either starts up, or delays for recovery and then starts, and the init script should just print progress indicators while that happens. I’m not sure a hardcoded timeout is a good idea. If there is a timeout, it should surely indicate whether the mysqld process is running or not, so the user has some idea that they should inspect manually before trying to start again.

By: Till

Till — Mon, 20 Aug 2012 18:35:53 +0000

Is 10 the best, or 1? ;)

Regardless – I understand your troubles. I think I never ran into these before and maybe just got lucky. I think I agree and the e.g. creating the data_dir is not the scope of an init script. Maybe I’ll work up a patch and send it to them.

I also agree the 15 seconds are kind of arbitrary. How would you suggest this is done instead?

I find Debian’s approach to connect to the database server for a ping not the best either. Start up time can vary depending on the size of the database and whatever it has to do to complete.

So yeah. Let me know what you would do instead or how a perfect start script would look like in your book, and I could roll this into a patch for them.

By: Xaprb

Xaprb — Mon, 20 Aug 2012 18:14:52 +0000

Till,

The FreeBSD script you reference has some of the braindead behaviors I hate. Example: if the data directory is empty, it creates a default data directory and starts the server anyway. I can’t count how many times I have seen a volume fail to mount because of a configuration error, leaving the bare mount directory. The stupid init script then sees this and starts MySQL on the root filesystem anyway. This is dumb. I did not ask the script to create a blank empty database with insecure user privileges, I asked it to start an existing database. If there is no existing database, that should be a fatal error and the process of starting MySQL should fail.

Another example is that it waits a hard-coded 15 seconds for the PID file to come into existence. This is completely naive.

So again, it has zero realistic error checking, actively harmful behaviors, and is overly simplistic. I would not praise it as one of the best, I would grade it a 3 on the scale of 1 to 10.

By: Xaprb

Xaprb — Mon, 20 Aug 2012 18:04:41 +0000

… and Gentoo’s init scripts are busted too, of course. Remove the socket file (perhaps by accidentally starting up a second instance, which detects the first instance is running and shuts itself down, in the process removing the pid file and socket file), and then try to “/etc/init.d/mysql restart” on Gentoo. Face-palming ensues. Why do people write init scripts that assume a pid/socket file is the source of truth about whether something is up and running?