Upstart config file generation

[Jan Ceuleers]

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).

[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.

Thanks, Jan