Upstart config file generation

[Steffen Barszus]

On Sat, 07 May 2011 11:36:38 +0200
Jan Ceuleers <jan.ceuleers at computer.org> wrote:
> I was more thinking about an ugly hack such as the following:
> 
>      start on (<base dependencies>
>      #include <mythtv-tuners/*.conf>
>      )
> 
> Each tuner would have a corresponding file in /etc/init/mythtv-tuners 
> with contents such as the following
> 
>      # /etc/init/mythtv-tuners/tuner1.conf
>      and pvrusb2-device-added KERNEL=sn-7157879
> 
> which would be added to the start on stanza.

That doesnt really solve your problem, as you would still require to
know IF ALL devices you are interested are there now, everything else
you are not really interested in. 

Saying that, i'm coming from a very similar field (yavdr) maybe with
slightly different perspective (vdr) 

> This makes it easier for applications to modify the startup triggers 
> without having to generate the entire Upstart configuration file. The 
> latter would require a (preferably standardised) way of combining a 
> generic template with installation-specific triggers. The former
> rolls this into Upstart proper, although perhaps a cleaner way of
> doing this can be found.

I believe we have a quite similar reqirement here ... so i hope its not
off topic, but adding some value.

try to not concentrate to much on the devices. We solved that by an
udev trigger which executes a script, firing at device addition we are
interested in (dvb, v4l) which then checks if all devices are complete
now. Once this check is true, an upstart event has been fired, on which
the application (vdr) started. 

This has been accompanied with an upstart job, starting after hardware
init is finished (stopped udevtrigger) which checked the available
hardware and changes the "save state". 

This might wait to long/has one device to less until the next reboot,
but that worked quite well. 

At current development version, we have changed that to a vdr plugin
listening to udev for /dev/video? /dev/dvb/..... adding the devices on
the fly. 

For remotes we have solved that with the use of eventlircd, which is
doing something similar. It starts the lircd socket and then keeps
adding the remotes with udev. 

What remains at complexity of upstart setup is:
- network (for the backend, if configured or in use by plugins)
- X (for the frontend)
- alsa/sound (for the frontend)
- synchronisation of backend with the frontend (depending on which one
  is configured, network or file socket)
- requirements of the plugins (i.e. mysql DB ) 


Considering the start up time of several seconds and the use as "sort
of kiosk application" (the user just wants to watch TV) its important
to start the backend earliest possible and still making sure all parts
are working. 

If you try to consider this requirements on the different paths as
boot , restart of one of the components, it can become quite complex ...

Speaking about the relation to upstart for this problems: 

1. network: this could be archived by a seperate job start on starting
   of the backend. States would be useful here, as we are interested in
   network being available not network becomes available. On the long
   run the application should handle network coming and going more
   gracefully, considering that network servicing is not the main
   service provided.
2. alsa - assumption is, that its enough to wait for the first snd
   device (udev-upstart-bridge) 
3. backend/frontend sync - here i hoped socket-upstart-bridge to be
   more then a sort of inetd replacement, i don't want to wait with the
   backend until the frontend can start which starts on socket of the
   backend. i would want to start something once someone is providing
   the socket to simplify the task
4. populating common information for a couple of applications ,
   i.e. DISPLAY variable (sessions ?)
5. specific upstart jobs possible to be started or stopped by non-root
   user
6. starting applications with a non-root user 
   (user <systemuser> keyword)
7. a kill timeout unlimited would be a usefull addition, to not have
   the need of using pre-stop script kill $(pidof ...)

This makes me think, that the planned features should be completed
first and seeing what requirements are left. Also the time should be
invested in making the applications more flexible on their
requirements instead of throwing this into the upstart domain.
mythtv/vdr requirements are not set in stone either.  

To ubuntu: i really hope that the boot and shutdown is handled soon by
upstart, and not by System-V scripts which proved to cause all kind of
race conditions. 

 On a last note: driver developer should get the drivers fixed,
as it seems some devices are broken if accessed to early, which more
likely happens with something like udev and upstart seeing the devices
becoming available and react on it. 

Mastering upstart is in fact mastering upstart, driver, application and
(if in use) ubuntu bugs not beeing used that way since decades as System
V. (Hope this is not to much of a rant ;) )