Upstart config file generation

[Clint Byrum]

Excerpts from Jan Ceuleers's message of Sun May 01 13:01:36 -0700 2011:
> On 01/05/11 21:17, Clint Byrum wrote:
> > In this case, the tuner intialization should emit an event that can
> > generically be used by anything requiring them. Either do it in an
> > upstart task:
> >
> > # initialize-tuners
> > start on startup
> > task
> > exec /usr/sbin/initialize-tuners
> 
> Yeah, I thought about this. But I think it just shifts the problem 
> elsewhere. The above binary would have to examine the MythTV 
> configuration (which is stored in mysql), and try to determine which 
> udev events to wait for based on the tuners listed there.
> 
> In the example shown at [1], it would need to somehow deduce that the 
> availability of /dev/video0 is signalled by pvrusb2-device-added 
> KERNEL=sn-7157879 and the availability of /dev/video1 by 
> pvrusb2-device-added KERNEL=sn-7117063. (I did try waiting for the 
> /dev/video? devices, but they seem to be created before they are ready 
> for use and so the backend would still start prematurely).

So the -added event isn't useful it sounds like. Whatever is doing the
initialization needs to emit an event when it is done.

If there are multiple devices like this, and some of them aren't for
mythtv.. I think its ok for the package to just delay mythtv until
they are all done. We have the same problem with network devices and
the solution, going forward, is to either make services robust enough
to work properly with or without the constituent parts, or delayed until
all devices are configured.

Sometimes this is as simple as having the service sent a SIGHUP after
every network device is fully configured, causing the service to consider
the configuration fully. Maybe mythtv needs something like this.

> 
> [1]: http://www.mythtv.org/wiki/Upstart_mythbackend_Configuration
> 
> > I'm working on a new wait-for-state.conf (which I hope to upload this
> > coming week to Oneiric, and will submit upstream for inclusion) which
> > will make it this easy:
> >
> > if [ -x /usr/sbin/mysqld ]&&  [ -f /etc/init/mysql.conf ] ; then
> >    start wait-for-state WAIT_FOR=mysql WAIT_STATE=started WAITER=mythtv WAIT_FOREVER=1
> > fi
> 
> OK, but this would make mythtv wait for mysql if mysql is installed. I 
> guess that this captures most use cases, but even if mysql is installed 
> on the same host as the mythtv backend this does not mean that mythtv is 
> configured to use the mysql instance on that server as opposed to some 
> other server.
> 
> I guess that examining /etc/mythtv/config.xml (or in older versions of 
> mythtv /etc/mythtv/mysql.txt) would allow us to detect this, as this 
> file contains the mysql server hostname for mythtv to use.

Its not important whether or not mythtv does use the local mysql
server. Whats important is just that the ordering is right *if* it
wants to.

Parsing the config is a noble idea, however I think this may be an overly
careful approach. Just make mythtv wait for the local mysql server if
its present. It covers both cases quite well, and the costs are minimal
(waiting a bit for a local mysql server).  I should have noted that if
mysql isn't already starting, the wait-for-state job will try to start it.