[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 
http://www.gossamer-threads.com/lists/mythtv/users/370119#370119 .

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.

Mike


More information about the mythtv-users mailing list