[mythtv-users] everyday i have to make sure myth worked the day before

Brian J. Murrell brian at interlinx.bc.ca
Sun Apr 3 00:22:07 UTC 2011


On 11-04-02 08:06 PM, Jam wrote:
> 
> sandypit:~ # cat chkmyth 
> #!/bin/bash
> pid=`cat /var/run/myth.pid`
> [ -f /proc/$pid/status ] && exit
> /usr/sbin/rcmythtv start
> 
> sandypit:~ # cat /etc/init.d/mythtv 
> #! /bin/sh
> ### BEGIN INIT INFO
> # Provides:          mythtv-backend
> # Required-Start:    $ALL
> # Required-Stop:     $null
> # Default-Start:     3 5
> # Default-Stop:      0 1 2 6
> # Short-Description: Start/Stop the MythTV server.
> ### END INIT INFO
> 
> PATH=/usr/bin
> DAEMON=/usr/local/bin/mythbackend
> NAME="mythbackend"
> DESC="MythTV server"
> 
> case "$1" in
>   start)
> #	export MYTHCONFDIR=/usr/local/share/mythtv
>         /bin/su - root -c "$DAEMON --daemon --logfile /var/log/mythback.log --
> pidfile /var/run/myth.pid"
>         ;;
>   stop)
>         killall mythbackend
>         ;;
>   restart|force-reload)
>         killall mythbackend
>         $DAEMON --daemon --logfile /var/log/mythbackend --pidfile 
> /var/run/myth.pid
>         ;;
>   *)
>         N=/etc/init.d/$NAME
>         echo "Usage: $N {start|stop|restart|force-reload}" >&2
>         exit 2
>         ;;
> esac
> 
> exit 0
> 
> sandypit:~ # crontab -l
> # DO NOT EDIT THIS FILE - edit the master and reinstall.
> # (/tmp/crontab.XXXX3ShaWC installed on Tue Oct 19 18:14:31 2010)
> # (Cron version V5.0 -- $Id: crontab.c,v 1.12 2004/01/23 18:56:42 vixie Exp $)
> # min hour date mon day-of-week
> * * * * * /root/chkmyth
> 
> and finally
> sandypit:~ # ll /usr/sbin/rcmythtv 
> lrwxrwxrwx 1 root root 18 2010-08-08 17:12 /usr/sbin/rcmythtv -> 
> /etc/init.d/mytht

And how does any of this relate to a mythbackend process that does not
actually die but continues to run, albeit, deadlocked so it is (a) not
allowing connections and possibly (b) not recording scheduled recordings?

I'm not sure how many times I have to explain that my backend process is
not outright DYING but is deadlocked and so "nanny" processes to check
for a non-existent backend and start one are not solutions here.

Indeed, if the backend were simply dying, I *could* fix that.  Deadlocks
likely require a much deeper understanding of the scheduling and
threading within the core of the backend.

b.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 262 bytes
Desc: OpenPGP digital signature
Url : http://www.mythtv.org/pipermail/mythtv-users/attachments/20110402/fc2f56b9/attachment.bin 


More information about the mythtv-users mailing list