Races with mysql upstart job

[Daniel Miller]

A suggestion. Some services are dependent on database backends, and depending on the service it's important to speed up the startup. In my case, using pdns, I need Mysql started as soon as possible - so pdns can start - so other networking services can resolv dns!

Is there a problem with changing the upstart script start line to:

start on (local-filesystems and net-device-up)

instead of using runlevels?

[Robie Basak (racb)]

Thank you for taking the time to report this bug and helping to make Ubuntu better.

Are you aware that you can override the behaviour on your system by using an upstart override file?

I'm not sure that it makes sense to make MySQL a special case here, but I'm interested to hear others' opinions on this.

[Serge Hallyn (serge-hallyn)]

I don't know whether the proposed start on is sufficient, but am marking this bug confirmed as tightening it down would be good.

[Robie Basak (racb)]

At a broader level, I'd like to see us better define some general guidelines for what server upstart scripts should be doing. The upstart documentation is very good at telling us how to achieve things based on what we want to achieve, but I couldn't find much information on what we should be doing in general for server daemons. I think that tightening this down definitely makes sense, but this can only be done in consideration with what other daemons' upstart scripts should also be doing.

[Robie Basak (racb)]

In this case for example, the requirement is that MySQL is started before DNS services can be made available. An alternative scenario (and perhaps more common) is when MySQL replication is being used, where MySQL may itself depend on DNS services being available. DNS services may require pdns or bind or dnsmasq. So can we even come up with a scheme that covers all use cases?

[Daniel Miller (dmiller)]

Without disparaging that last comment - I would argue that the percentage of single-server or workstation installs is greater than those with multi-server or replication environments - and that such environments will have staff with a higher competence level to adjust non-default settings for their optimum purpose.

MySQL is a common base for several services, so having it available as soon as possible is important. Obviously, I believe the goal is to have not only all services controlled via "pure" upstart scripts, but to have them started via relevant triggers. I'll probably post additional requests like this one on the other service packages I use - including Postgresql, PowerDNS, Dovecot, and Postfix.

[Daniel Miller (dmiller)]

Having changed my mysql.conf as described above, and added "start on started mysql" to pdns.conf, and "started on started pdns" to pdns-recursor.conf, my boot process comes through beautifully.

[Daniel Miller (dmiller)]

Oops - make that last "start on started pdns" in pdns-recursor.conf.

[Clint Byrum (clint-fewbar)]

This sounds like a bug in pdns, not mysql.

At this time, there is no earlier set of events we can use than runlevel [2345]. MySQL requires that the static network be up and working and that all filesystems be mounted, which is what runlevel 2 triggers on. On my 2008 model macbookpro w/ slow disk, this is 36 seconds after the kernel starts. On my mac book air w/ SSD, this is 6 seconds after the kernel starts. The proposed start on would not be sufficient on systems with more than one static network interface.

pdns, however, seems to still be controlled by an init.d script. So that is problem #1. If it cannot handle being started before a local dependency (I'd argue that is a bug as it should be able to poll for quite a while at startup), then it needs an upstart job which can wait for mysql to start in its pre-start:

pre-start script
  if [ -f /etc/init/mysql.conf ] ; then
    start wait-for-state WAIT_FOR=mysql WAITER=pdns
  fi
end script

That will spin for up to 30 seconds after trying to start mysql (or forever if you set WAIT_FOREVER=1) before returning. You can in fact use 'start wait-for-state ...' in an init.d script as well for the same purpose, so you don't actually have to write an upstart job.

Anyway, I'm redirecting this as a bug in pdns, not mysql. I don't see anything that mysql can change to help dependent services deal with the fact that they haven't in any way declared or even tried to deal with those dependencies.

[Chris Hofstaedtler (zeha)]

pdns in default configuration will retry starting until MySQL is up.

[Launchpad Janitor (janitor)]

[Expired for pdns (Ubuntu) because there has been no activity for 60 days.]