Difference between revisions of "Upstart mythbackend Configuration"

Revision as of 20:42, 9 October 2011

Some newer Linux distributions replace the traditional initscript startup management process with a program called upstart, which does things differently; here are some notes on how to make MythTV play nicely with upstart.

Default configuration

name=Upstart mythbackend Configuration author=Mario Limonciello webpage=none short=Upstart mythbackend Configuration long=Upstart configuration file for starting mythbackend. file=none category=Startup Scripts supports=S21:unset,S22:unset,S23:unset,S231:unset,S24:unset,S241:unset,S25:unset,S251:unset,S252:unset,S26:unset,S27:unset,S28:unset,S29:unset,S30:unset,S31:unset,S32:unset,S33:unset,S34:unset

Save the configuration file below in /etc/init/mythtv-backend.conf and create a symlink referencing the upstart-job binary in /etc/init.d or /etc/rc.d/init.d.

ln -s /lib/init/upstart-job /etc/init.d/mythtv-backend

# MythTV Backend service

description     "MythTV Backend"
author          "Mario Limonciello <superm1@ubuntu.com>"

start on (local-filesystems and net-device-up IFACE=lo)
stop on starting shutdown

#expect fork
respawn

script
        ulimit -c unlimited     # Note 1.
        . /etc/default/locale   # Note 2.
        export LANG
        export LC_ALL=$LANG
        USER=mythtv
        ARGS="--logfile /var/log/mythtv/mythbackend.log --user $USER"
        test -f /etc/default/mythtv-backend && . /etc/default/mythtv-backend || true
        /usr/bin/mythbackend $ARGS $EXTRA_ARGS
end script

Delay starting the backend until all tuners have initialised

Some tuners take a long time to initialise and may therefore not yet be available when the backend starts. Since the backend only tests the presence of tuners upon startup, tuner initialisation needs to have completed before the backend is started.

This is accomplished by adding additional events to the and clauses in the start on stanza. An example follows:

start on (local-filesystems and net-device-up IFACE=lo and pvrusb2-device-added KERNEL=sn-7157879 and pvrusb2-device-added KERNEL=sn-7117063)

Consult the Upstart Intro, Cookbook and Best Practices for details about how to determine the correct events. Briefly:

• Use the following command to list all possible event types on your system:

for subsystem in /sys/class/*
do
  for action in added changed removed
  do
    echo "${subsystem}-device-${action}"
  done
done

• Determine which of these event types correspond with your tuners. For example, when a Hauppauge HVR-1900 tuner finishes initialisation this results in a pvrusb2-device-added event.
• If you have only one tuner, or only one tuner of each type, then you are done: just add the corresponding events to your start on stanza without additional parameters.
• If you however have multiple tuners that result in the same event type upon initialisation, then you want to delay starting the backend until they have all initialised. You therefore need to find a way to tell the tuner initialisation events apart. In the above example this is done by noting that the KERNEL environment variable contains the tuner's serial number when the event is triggered.
• In order to find out which environment variables are available when an event is triggered, create a test Upstart configuration file such as the following, which logs the environment to a file:

start on (pvrusb2-device-added)
script
  echo "\n`env`" >> /dev/.initramfs/test.log
end script

Don't forget to delete the test Upstart config file when you are done.