[mythtv] [mythtv-commits] Ticket #7762: Autoshutdown slave feature enhanced

[Guillaume Membré]

On Thu, Feb 11, 2010 at 1:49 AM, Chris Pinkham <cpinkham at bc2va.org> wrote:
> * On Wed Feb 10, 2010 at 09:28:04PM -0000, MythTV wrote:
>> #7762: Autoshutdown slave feature enhanced
>
>> Comment(by anonymous):
>>
>>  Thanks for the attention cpinkham,
>>
>>  I am testing this patch because I have a couple of problems with [20084]
>>  as found in my 22759 svn, that I thought this may help with. I haven't
>>  reported them elsewhere yet but was planning on it.
>>
>>  * I'm getting a race condition or similar shutting down the SBE just after
>>  a transcode job has begun from a cron wakeup (since the SBE cannot refuse
>>  to shutdown in the original incarnation)
>>
>>  * And also it would be nice if the JobQueue could wake up SBEs that are
>>  sleeping.
>
> Yeah, the code was really written with dedicated slave backends in mind,
> ones that only wake up when told to do so by the master backend.  I have
> some items on my TODO to implement functionality like the above, but they
> are a ways down the list, so I'm glad someone sees use in the functionality
> and is working on it.  My eventual goal is to have the JobQueue be like the
> scheduler, where the master backend is the only server managing the
> queue and it grabs jobs and assigns them to hosts, so it could wakeup and
> shutdown slaves as desired (aka configure by the user).
>
>>  The patch has merit, the use of an OK or BUSY response based on a check of
>>  mythshutdown is great, just seems there are a few issues with the
>>  implementation - you mention ''way'' more than I could find.
>
> Yes, I'd like to get the patch into trunk.  I ran out of time to look at it
> before the feature freeze for 0.23, but I hope to get something in for 0.24.
> When that happens depends on when the patch is updated.  Unfortunately,
> I have a bunch of other higher priority things on my plate, so it would help
> if the issues could be addressed by someone else and a new patch uploaded to
> the ticket.
>
>>  I'm running the Feb 9 version of the patch now, but it still has problems.
>>  True I am running a version earlier than the patch was written for, and I
>>  am seeing socket problems as follows:
>
>>  2010-02-10 20:56:35.370     Asking Server to go to sleep.
>>  2010-02-10 20:56:35.546 MainServer::ANN Monitor
>>  2010-02-10 20:56:35.548 adding: Server as a client (events: 0)
>>  2010-02-10 20:56:35.551 MainServer::ANN Monitor
>>  2010-02-10 20:56:35.553 adding: Server as a client (events: 1)
>>  2010-02-10 20:57:05.373 MythSocket(a1f7858:31): readStringList: Error,
>
> I'm curious what the two announcements are right after the master tells
> the slave to go to sleep.  Are those from mythshutdown running on the
> slave?
>
> If you can reproduce this consistently, can you run your master and slave
> backends with "-v network,extra" and reproduce the issue and reply with
> the relevant portions of the logs from each.
>
>>  Since I am stuck with a system that doesn't work properly I will back out
>>  the change for now and look at upgrading to 22882 to test further.
>
> If possible, please get the logs requested above before backing out the
> patch.
>

With Simon, we found the origin of the problem : when "mythshutdown -c
1" is executed as a preSDWUCommand command by the SBE, mythshutdown
freezes until a timeout occurs for the GO_TO_SLEEP command coming from
the MBE to SBE. *I don't know why.* Then the MBE thinks an error
occurs on the slave and sets the status of the tuner to undefined.
Nevertheless, on the slave side, the mythshutdown is unblocked and
return a valid value which allow a shutdown. Thus, the SBE shutdowns
itself normally.
But as the MBE sets a wrong status for the SBE, it will never wake it
up again for a new recording or the dailywake up period.

If "mythshutdown -c 0" is configured as a preSDWUCommand, everything is fine.
Using "mythshutdown -c 1" may be unrevelant as this command checks for
the status of the tuner of the current slave, the auto shutdown
feature also checks the status of the tuner on the MBE side and it
doesn't ask a SBE to go to sleep if any of its tuner is (or will be)
active.

I think the same problem will occurs with ""mythshutdown -s 1"

the latest patch (shutdownSlaveEnhanced_v0.3.diff) is working fine,
except with "mythshutdown -c 1"

Regards
Guillaume