[mythtv-users] Shutdown/Startup help

Craig Huff huffcslists at gmail.com
Wed Sep 19 18:53:38 UTC 2007


On 9/19/07, Mike Perkins <mikep at randomtraveller.org.uk> wrote:
>
> Now I have just about got my system to the "walk away quietly" stage[1], I
> would
> like to shut down my systems overnight to save energy, theoretically, at
> any
> rate. I have followed the various methods for shutdown and startup in the
> lists,
> but they are not really appropriate. I'm sure I saw something a long while
> ago,
> perhaps when I first came here, but I can't find anything relevant in the
> lists[2], so any suggestions gratefully received...
>
> My setup consists of a mixture of Myth and non-Myth. I have a backend-only
> master server, a frontend, several workstations, one of which is a slave
> backend
> as well, and a couple other servers. One of these other servers is the
> "server
> to rule them all", a mini-ITX box and runs DHCP, LDAP[3], two printers, a
> scanner, oh, and LTSP which is handy for when I build my diskless
> frontend...
>
> All of my boxes also run Bacula, which means each box has to be alive at
> some
> time or other to be backed up. All the boxes respond to wake-on-lan, so
> I've no
> problem there.
>
> So I have recordings, mythfilldatabase, possible overnight transcodes,
> bacula
> saves, actually watching stuff and normal use of workstations to
> coordinate. I
> remember seeing something about writing to a file on the master server,
> which
> then triggers off stuff, but I can't find it.
>
> As I say, suggestions gratefully received.
>
> Mike Perkins
>
> [1] Of course, I am about to destabilise things with what I am asking
> for...
>
> [2] I know. Even Goooogle defeats me sometimes.
>
> [3] I hope to use LDAP to control logins, Samba, DHCP, etc, etc. Anyone
> out
> there who would be willing to share experiences, preferably off list...
>
> _______________________________________________
> mythtv-users mailing list
> mythtv-users at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
>


Mike,

Caveats:  I know what Backula is, but haven't used it.  Don't know what LTSP
is.
Know enough that I don't want to mess with LDAP badly enough to learn it.
Only
tried Suspend2 (now TuxOnIce) for suspending Linux boxen.  Only used Fedora
Core distros.

I have my systems using the ACPI wakeup functionality rather than
nvram-wakeup
and Suspend2 to power down when not in use.  Since they are *all* MythTV
systems,
they all use MythShutdown which in turn calls a shell script of mine to do
more house-
keeping before calling the Suspend2 command "hibernate".  My housekeeping
includes
determining whether the box should wake up *earlier* than MythTV thinks it
should,
in my case to comply with the "Suggested next fill time" from Schedules
Direct.  It
has been reported that this is more of a suggestion than a demand, but I
already have
the system in place, so...  This could be extended in your case to reference
a config
file of your choosing to obtain times for extra activities, like when the
system should
be "awake" to do Backula backup work.

I have also configured my systems so the frontends use Wake-on-lan to wake
up
the backend.  If/when I set up a slave backend, I would set up the backend,
in turn, to
wake it/them up with WOL.

Notes:
1) I found out (the hard way, naturally) that current Linux kernels support
ACPI by
default rather than APM, which is what nvram-wakeup uses as documented.
I suppose one could figure out how to use it to modify the ACPI alarm clock
settings,
but it wasn't exactly obvious how.  APM and ACPI are at least treated as
mutually
exclusive, although I don't know that they *are*.  I had nvram-wakeup all
set and
couldn't get the !*&#@6489 system to wake up until I learned this and
switched to
ACPI functions built into the kernel.
2) Around Linux kernel release 2.6.21 (FC6) and the match for Fedora 7, the
built-in
ACPI support interface changed and broke my systems' ability to wake by RTC
alarm.
I had to roll back my kernel to 2.6.20.  YMMV.
(See my bug report http://bugzilla.kernel.org/show_bug.cgi?id=8995)
3) The old ACPI interface is to read/write to /proc/acpi/alarm to see the
time format
and write new alarm times.  Typically, systems use UTC time, not local time,
unless
they're dual-booting Windoze, so the alarm times have to be UTC times, not
local
times.  With this old interface, at least the Fedora Core kernels need a
tweak to
/etc/init.d/halt because, at least *my* motherboards, reset the alarm if the
rtc is
updated, which is part of the default halt processing.  I had to modify
/etc/init.d/halt
to check if the alarm was set and, if so, skip posting the system time to
the RTC.
This wasn't an issue for me since I'm running ntpd anyway to get time
adjustments
from the internet.
4) The new ACPI interface, which as I mentioned above doesn't work for me,
is to
read/write to /sys/class/rtc/rtc0/wakealarm the seconds since the Unix
epoch.  That's
not as bad as it sounds (really!).  It just means you ought to use the date
command
to translate for you.  The present time in this format is returned by "#
date -u +%s".
Read the man-page for details on how to specify other times (like when the
system
should wake up for Backula runs).  I don't know whether this new interface
has the
same issue with /etc/init.d/halt, but it does have another twist:  The alarm
must be
reset before it can be set/changed.  Resetting is reportedly generically
achieved by
setting to *any* past time value, but it is simplest to just set it to zero
(e.g.:
    "# echo 0 > /sys/class/rtc/rtc0/wakealarm; \
         echo $time_to_wakeup > /sys/class/rtc/rtc0/wakealarm").

If this hasn't overwhelmed you and you have questions, I'll try to answer
them (if
someone else doesn't beat me to it). ;-)


Craig.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mythtv.org/pipermail/mythtv-users/attachments/20070919/6a2f284c/attachment.htm 


More information about the mythtv-users mailing list