[mythtv-users] Mythbackend occasionally upon reschedule

Michael T. Dean mtdean at thirdcontact.com
Sun Nov 11 06:06:21 UTC 2007


On 11/10/2007 07:25 PM, Steve Skarda wrote:
> On Nov 10, 2007 5:07 PM, Michael T. Dean <mtdean at thirdcontact.com> wrote:
>> On 11/09/2007 11:18 AM, Steve Skarda wrote:
>>     
>>> Mythbackend dies roughly 1-2 times a day.  It did this on stable
>>> version and continues to do it on SVN trunk.  I am posting the last
>>> items in the log on the last several crashes (on latest trunk from
>>> mythbuntu weekly builds).  It always ends with reschedule requested.
>>>       
>> Are you sure it's the reschedule that crashes it?  Reschedules happen
>> quite often, so it's quite possible that was the last thing written to
>> the log, then later, mythbackend crashed.
> Thank you for replying!
>
> Monit runs every 60 seconds.   If I compare the timestamp when Monit first
> saw that mythbackend was gone, to the timestamp in the mythbackend log, the
> last thing in the log before restart is the reschedule request and it is
> typically 20-30 seconds before monit sees that mythbackend is gone.
>
> You have caused me to wonder about something else though.  Monit doesn't say
> that process doesn't exist which is what happens if I kill mythbackend.
> Rather it says that mythbackend failed HTTP test.
>
> This is what I see in monit log:
>
> [EST Nov 10 09:02:14] error    : HTTP: error receiving data -- Resource
> temporarily unavailable
> [EST Nov 10 09:02:14] error    : 'mythbackend' failed protocol test [HTTP]
> at INET[localhost:6544] via TCP
> [EST Nov 10 09:02:15] info     : 'mythbackend' trying to restart
> [EST Nov 10 09:02:15] info     : 'mythbackend' stop: /bin/sh
> [EST Nov 10 09:02:16] info     : 'mythbackend' start: /bin/sh
> [EST Nov 10 09:02:47] info     : 'mythbackend' connection passed to
> INET[localhost:6544] via TCP
>
> Maybe I should try to modify my monit monitoring configuration?

Constantly pinging the backend status page is "known" to cause
mythbackend to crash.  I'd bet that your proactive approach to handling
the crashes--monitoring with monit so you can restart after a crash--is
what's causing the crashes.

By "known" I mean generally recognized, though the cause is unknown. 
Others may have more info (or more correct info).

Mike


More information about the mythtv-users mailing list