[mythtv] [mythtv-commits] Ticket #5210: Automatic shutdown for SBE

[Chris Pinkham]

* On Fri Dec 05, 2008 at 01:43:24AM -0500, f-myth-users at media.mit.edu wrote:
>> format MAC address.  In this case, the master would just use a
>> SendWOL(QString MAC) method in backendutil.cpp rather than relying on the
>> user to install another WOL binary.
> 
> If you do that, here's something that might save some headscratching:
> if the MAC is 01:02:03:04:05:06:07:08, send a WOL package for both
> that MAC -and- one in reversed byte order (08:07:06:05:04:03:02:01).

Thanks, I put this in my TODO.

> Also, some chipsets require that the packet be sent to the broadcast
> address and -not- just to the IP address of the relevant machine;

The 'wakelan' program I'm currently using sends to the broadcast, all I
specify on the command line is the MAC address.  I was planning on
implementing the same functionality where only the MAC was required.

> The other issue is that slaves will have to arrange to do something
> like "ethtool -s eth0 wol g" (the Ubuntu default seems to be "d",

Since WOL is just one of the many ways that a server could be resumed,
I was leaving that up to the user in their 'SleepCommand' script which
gets run on the slave.

WakeUpCommand = run on master to wakeup a sleeping slave.  This command
could do anything, from sending a WOL packet to toggling a bit on a
serial port to flip a relay to sending an X10 command to turn on a
remote receptacle.

SleepCommand = run on slave to put itself to 'sleep'.  This could be
anything from a regular shutown, a 'poweroff -f' like I do on my nfsroot
servers, or sending an X10 command to turn a receptacle off.

The user is the one implementing these commands, so I was leaving the
details up to them.  The only reason for putting a small utility
function in for sending a WOL packet is to save the user from having to
install another binary and we can utilize the WOL code in other places
in Myth as well.

> I know this is klugy, but it's a fairly small amount of hair, and
> might eliminate a lot of "why isn't my backend waking up again?"
> sort of traffic on the lists...

Easy enough for them to test.  Run the SleepCommand on the slave and
see if it shuts down (or whatever it's supposed to do).  Then run the
WakeUpCommand on the master and see it if brings the slave back to life
and reconnects to the master backend.

I tested my patch some last night and it is working as intended.  The
master is commanding an inactive slave to shutdown and waking it up
again when necessary.  I need to add in a bit more code to do things
like attempting to wake up all slaves when the master first starts so
that the master can get a proper indication as to what slaves are
available so scheduling can be done properly.  I also need to detect
a little better when a slave is in use for instance if it is being
used to stream a recording or run jobs in the JobQueue.  When a slave
is asleep, it's as if it was never connected to the master except
for purposes of scheduling future recordings.  The master will not
try to wakeup the slave for anything but a scheduled recording.  This
means LiveTV can't use those tuners unless the slave is already awake.
The main idea is to allow slaves without local storage to be shutdown
when idle.  I have diskless frontends and diskless backends as well,
even my master uses nfsroot.  There's no need to keep a slave up 24x7
when if it's tuners are only used a few hours a day (or week in the
case of some of my tuners).

--
Chris