On 9/19/07, <b class="gmail_sendername">Mike Perkins</b> <<a href="mailto:mikep@randomtraveller.org.uk">mikep@randomtraveller.org.uk</a>> wrote:<div><span class="gmail_quote"></span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Now I have just about got my system to the "walk away quietly" stage[1], I would<br>like to shut down my systems overnight to save energy, theoretically, at any<br>rate. I have followed the various methods for shutdown and startup in the lists,
<br>but they are not really appropriate. I'm sure I saw something a long while ago,<br>perhaps when I first came here, but I can't find anything relevant in the<br>lists[2], so any suggestions gratefully received...
<br><br>My setup consists of a mixture of Myth and non-Myth. I have a backend-only<br>master server, a frontend, several workstations, one of which is a slave backend<br>as well, and a couple other servers. One of these other servers is the "server
<br>to rule them all", a mini-ITX box and runs DHCP, LDAP[3], two printers, a<br>scanner, oh, and LTSP which is handy for when I build my diskless frontend...<br><br>All of my boxes also run Bacula, which means each box has to be alive at some
<br>time or other to be backed up. All the boxes respond to wake-on-lan, so I've no<br>problem there.<br><br>So I have recordings, mythfilldatabase, possible overnight transcodes, bacula<br>saves, actually watching stuff and normal use of workstations to coordinate. I
<br>remember seeing something about writing to a file on the master server, which<br>then triggers off stuff, but I can't find it.<br><br>As I say, suggestions gratefully received.<br><br>Mike Perkins<br><br>[1] Of course, I am about to destabilise things with what I am asking for...
<br><br>[2] I know. Even Goooogle defeats me sometimes.<br><br>[3] I hope to use LDAP to control logins, Samba, DHCP, etc, etc. Anyone out<br>there who would be willing to share experiences, preferably off list...<br><br>
_______________________________________________<br>mythtv-users mailing list<br><a href="mailto:mythtv-users@mythtv.org">mythtv-users@mythtv.org</a><br><a href="http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users">http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users
</a><br></blockquote></div><br><br>Mike,<br><br>Caveats: I know what Backula is, but haven't used it. Don't know what LTSP is.<br>Know enough that I don't want to mess with LDAP badly enough to learn it. Only
<br>tried Suspend2 (now TuxOnIce) for suspending Linux boxen. Only used Fedora<br>Core distros.<br><br>I have my systems using the ACPI wakeup functionality rather than nvram-wakeup<br>and Suspend2 to power down when not in use. Since they are *all* MythTV systems,
<br>they all use MythShutdown which in turn calls a shell script of mine to do more house-<br>keeping before calling the Suspend2 command "hibernate". My housekeeping includes<br>determining whether the box should wake up *earlier* than MythTV thinks it should,
<br>in my case to comply with the "Suggested next fill time" from Schedules Direct. It<br>has been reported that this is more of a suggestion than a demand, but I already have<br>the system in place, so... This could be extended in your case to reference a config
<br>file of your choosing to obtain times for extra activities, like when the system should<br>be "awake" to do Backula backup work.<br><br>I have also configured my systems so the frontends use Wake-on-lan to wake up
<br>the backend. If/when I set up a slave backend, I would set up the backend, in turn, to<br>wake it/them up with WOL.<br><br>Notes:<br>1) I found out (the hard way, naturally) that current Linux kernels support ACPI by
<br>default rather than APM, which is what nvram-wakeup uses as documented.<br>I suppose one could figure out how to use it to modify the ACPI alarm clock settings,<br>but it wasn't exactly obvious how. APM and ACPI are at least treated as mutually
<br>exclusive, although I don't know that they *are*. I had nvram-wakeup all set and <br>couldn't get the !*&#@6489 system to wake up until I learned this and switched to<br>ACPI functions built into the kernel.
<br>2) Around Linux kernel release 2.6.21 (FC6) and the match for Fedora 7, the built-in<br>ACPI support interface changed and broke my systems' ability to wake by RTC alarm.<br>I had to roll back my kernel to 2.6.20. YMMV.
<br>(See my bug report <a href="http://bugzilla.kernel.org/show_bug.cgi?id=8995">http://bugzilla.kernel.org/show_bug.cgi?id=8995</a>)<br>3) The old ACPI interface is to read/write to /proc/acpi/alarm to see the time format
<br>and write new alarm times. Typically, systems use UTC time, not local time, unless<br>they're dual-booting Windoze, so the alarm times have to be UTC times, not local<br>times. With this old interface, at least the Fedora Core kernels need a tweak to
<br>/etc/init.d/halt because, at least *my* motherboards, reset the alarm if the rtc is <br>updated, which is part of the default halt processing. I had to modify /etc/init.d/halt<br>to check if the alarm was set and, if so, skip posting the system time to the RTC.
<br>This wasn't an issue for me since I'm running ntpd anyway to get time adjustments<br>from the internet.<br>4) The new ACPI interface, which as I mentioned above doesn't work for me, is to<br>read/write to /sys/class/rtc/rtc0/wakealarm the seconds since the Unix epoch. That's
<br>not as bad as it sounds (really!). It just means you ought to use the date command <br>to translate for you. The present time in this format is returned by "# date -u +%s".<br>Read the man-page for details on how to specify other times (like when the system
<br>should wake up for Backula runs). I don't know whether this new interface has the <br>same issue with /etc/init.d/halt, but it does have another twist: The alarm must be<br>reset before it can be set/changed. Resetting is reportedly generically achieved by
<br>setting to *any* past time value, but it is simplest to just set it to zero<br>(e.g.:<br> "# echo 0 > /sys/class/rtc/rtc0/wakealarm; \<br> echo $time_to_wakeup > /sys/class/rtc/rtc0/wakealarm").
<br><br>If this hasn't overwhelmed you and you have questions, I'll try to answer them (if<br>someone else doesn't beat me to it). ;-)<br><br><br>Craig.