[mythtv-users] everyday i have to make sure myth worked the day before
Michael T. Dean
mtdean at thirdcontact.com
Sun Apr 3 13:03:59 UTC 2011
On 04/03/2011 12:24 AM, Kenneth Emerson wrote:
>> 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.
> Until you can get a / true / fix for your problem, you may want to try using
> monit and monitor port 6544. If the backend is truly hosed, it won't be
> able to respond on that port.
> See: http://www.mythtv.org/wiki/Status_Monitoring_How_To
> I did use this for a while, but if you make the timeout too short, it will
> trigger when the backend is just busy and not hung. I haven't had your
> problem and currently only look for the pid missing out of the CPU queue.
> To use the port monitor, you'll have to experiment with your system to find
> an appropriate timeout value.
> Good luck!
Note that constant polling of the MythTV backend web server has--over
the years--cause /far/ more problems for users than "blindly" assuming
MythTV works properly. Constant polling can actually /cause/ the
problem the OP is seeing.
Therefore, if you /are/ running a monitor program (monit, nagios, ...),
you should really use a bindings-based script that checks to see if the
backend is running. Something like
Seems I need to get Raymond Wagner to rewrite that Perl-based hack into
a MythTV Python bindings script so we can post it on the wiki.
More information about the mythtv-users