[clug] Real Time Clock Alarm Power Management Management

[Hal Ashburner]

Hey Steve,

Thanks for your thoughts! I'm going to have to re-read them again tonight
fresh because I'm a bit fuzzy just now and also look up how cron does
scheduling "queues",

The way I'm seeing it is you have one place to tell the machine when to
switch itself on next.
You have many different applications that wish to set this that you want to
arbitrate between so the right thing happens next.

Once set, it may well expire without needing to be used as the machine was
already on at the time of the alarm so you want it to immediately replace
the contents with the next in the queue.
"Why haven't you shut down?" is less interesting than "why didn't you wake
up?"

(very roughly without thinking too hard just yet)
#date-time    #client
20120402-7:00      alarm_clock
20120402-11:00    mythtv
20120402-22:00    mythtv
20120403-07:00    cracking_toast_grommit


The disaster would be if the machine wasn't shut down between 7am and 11am,
then shut at 2pm with the alarm now set in the past so then the machine
failed to switch on at 10pm.


Do you mean just using the cron format so it becomes
#m h     d  m  day_of_week    requester
 00 07  02 04     *                   alarm_clock
 00 11  02 04     *                   mythtv

this way
 00 07  *   *   1-5    cracking_toast

gets it on for breakfast on weekdays but gives Grommit a well deserved
break on the weekend.


Automated shutdown occurs every 10 minutes already but checks a host of
things and declines to proceed if any of them are happening. On shutdown
you just make sure you've got that next valid wakeup time written out.

Clients could write to the file, or they could connect to the daemon via
unix domain socket and tell the daemon to manipulate the file. (Or DBus, or
DCop, or whatever people who know reckon is the best fit and likely not to
require massive maintenance with shifting libraries and the general CADT
"lets write a whole new one" approach.

Power_on_schedule group that says who can write to the file (or connect to
the daemon).

The whole thing becomes pretty simple. An hour or two of work at most, one
would think.

I can and will (in the absence of better advice) do it for the purposes of
my box. Given I want it, maybe others do as well? Maybe it's worth doing
properly(tm). But not doing more than "turn me on next tuesday fortnight at
7am" works and will happen, but doesn't stop it from switching itself on at
9am tomorrow.

Out of interest how are people doing alarm clocks on linux machines now? At
all? The machine is always on heating the room?



On 1 April 2012 12:10, steve jenkin <sjenkin at canb.auug.org.au> wrote:

> Hal Ashburner wrote on 1/04/12 8:58 AM:
>
> > I've failed to find something obvious that does this (written by someone
> > smarter than me - which goes without saying).
>
> sounds like you either want to modify cron/at, or more portably and with
> less effort, write a 'sleep-now' command that gets scheduled with "at"
> and cron.
>
> Using the cron scheduling queues saves you from creating a new queuing
> system with yet another control file. To implement your belt-and-braces
> check 'why aren't you asleep', you do need a status flag outside cron
> with a job scheduled every 1-15 minutes to check it, and if wrong, try a
> forced sleep.
>
> On the lines of modding 'cron', the terminal login control system (init
> & /etc/inittab) got modded to produce the first 'inetd'. SUN once had a
> bug where 'inetd' would shut down a port that was 'spawning too fast'
> (an error condition inherited from how init did serial terminals).
>
> In 1996, I saw a very elegant extension of 'cron' that allowed job
> dependencies (run this after that and that) and work could be scheduled
> "sometime within this window, but not before or after". I'm surprised
> more people have added useful stuff like this to the cron control files.
>
> Paul Bonscheck (?sp) and his company "Eclectic Vision" seem to have
> dropped off the face of the Internet since then :-(
>
> If you're looking to write code, I was always hugely impressed by Steve
> Landers toolkit (Functional Software) that become "The Admin Manager"
> (later COS-manager, IIRC). A set of utilities that did database
> operations on text files of all descriptions, including the output of
> commands ('ls' is a read-only table). [cut-join-paste + select + awk
> preprocessor that allowed use of named-fields, not $1, $2 etc]
>
> Like Oracle, they built the complex functions from a base set of simple
> tools. Instead of using 'binary blobs' locked up in a DB, they used
> tab-separated files for their many interrelated tables.
>
> [I'm not against DB's for what they do well: large collections of data,
> esp with in-place update of rows/fields. For systems tools, having
> everything in the filesystem means when you've got problems at boot time
> and only very primitive tools, you've got a chance to figure out what's
> wrong and even fix it.]
>
> I'm not suggesting you reinvent SteveL's work, but think along those lines.
>
> Is there a small, simple set of tools (read commands) you might
> construct that can be used to build a generic queuing system, the first
> instance of which manages the Real Time Clock for 'wake alarams' ?
>
> Of course, with the collective wisdom of the list, someone is likely to
> say "Oh, that's XXX" and all I've written is irrelevant :-(
>
> HTH
> steve
>
> --
> Steve Jenkin, Info Tech, Systems and Design Specialist.
> 0412 786 915 (+61 412 786 915)
> PO Box 48, Kippax ACT 2615, AUSTRALIA
>
> sjenkin at canb.auug.org.au http://members.tip.net.au/~sjenkin
> --
> linux mailing list
> linux at lists.samba.org
> https://lists.samba.org/mailman/listinfo/linux
>