init script unable to "start" after backend crash

Bug #118538 reported by Paul McEnery
6
Affects Status Importance Assigned to Milestone
mythtv (Ubuntu)
Fix Released
Wishlist
Mario Limonciello

Bug Description

The init script for mythbackend simply checks for the existence of the pid file. if the pid file exists, it assumes that mythbackend is running. This is not necessarily the case. If you have something like monit running to automatically restart in the event of a mythbackend crash, monit fails to perform a start of mythbackend because the init script exits with signal 1. I am fully aware that I could tell monit to "restart" instead of "start", but this is not a neat solution. It would be better for the init script to first check if there is in fact a mythbackend process before exiting with signal 1.

I will post a patch that I have created after modifying my init script to check for the existence of a process. Maybe someone can do a better job of the coding... This is not unique. In fact many of the init scripts perform a similar check. Can this or a more eloquent version of it be added to the standard package?

Related branches

Revision history for this message
Paul McEnery (pmcenery) wrote :
Revision history for this message
David Morris (dave-greenacre) wrote :

superm1 can you look at getting this packaged up if its suitable.

Changed in mythtv:
assignee: nobody → superm1
status: Unconfirmed → Confirmed
Revision history for this message
Kees Cook (kees) wrote :

This patch looks like a good start, however, I recommend some changes:
1) Move PID= definition higher, otherwise ARGS will not resolve it
2) use $() syntax instead of ``
3) drop the "else" section, otherwise "start" won't actually start when it removes a PID file
4) report that it is removing a "stale pid" file in the "start" section

Are there other services that do this that you can use for examples? Do the LSB tools (like start-stop-daemon) provide a way to deal with stale pid files already?

Changed in mythtv:
status: Confirmed → Needs Info
Revision history for this message
Paul McEnery (pmcenery) wrote :

Agreed my patch is probably more of a bug than a benefit, but hopefully we can come up with something that does the job effectively and efficiently. Initially I got most of the contents from an example jabberd init script I found on the web. dbus does something similar. here is what it does:

  if [ -e $PIDFILE ]; then
    PIDDIR=/proc/$(cat $PIDFILE)
    if [ -d ${PIDDIR} -a "$(readlink -f ${PIDDIR}/exe)" = "${DAEMON}" ]; then
      log_success_msg "$DESC already started; not starting."
    else
      log_success_msg "Removing stale PID file $PIDFILE."
      rm -f $PIDFILE
    fi
  fi

Hopefully the formatting doesnt get lost...

Possibly this would be a more elegant solution before the "start" command.

Revision history for this message
Brian J. Murrell (brian-interlinx) wrote :

Was just about to report this bug and saw it here already. The history is a few months old though. Can we revitalize this work and get it landed?

Changed in mythtv:
importance: Undecided → Wishlist
status: Incomplete → Confirmed
Revision history for this message
Mario Limonciello (superm1) wrote :

fix committed in bzr revno 40

Changed in mythtv:
status: Confirmed → Fix Committed
Revision history for this message
Mario Limonciello (superm1) wrote :

mythtv (0.20.2+fixes15096-0ubuntu2) hardy; urgency=low

  [ Mario Limonciello ]
  * mythtv-backend.init:
    - Require networking and remote file systems to be started before
      running. (LP: #149268)
    - Find the home directory of our USER and then create a symbolic
      link in that user's home directory for mysql.txt.
    - Add LSB support.

  [ Paul McEnery ]
  * More resilient init script PID handling (LP: #118538)

 -- Mario Limonciello <email address hidden> Mon, 17 Dec 2007 00:15:52 -0600

Changed in mythtv:
status: Fix Committed → Fix Released
Revision history for this message
darthanubis (darthanubis) wrote :

I'm running Hardy, and the script still dies upon boot. I have to manually run "mythbackend" from terminal.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.