stef at bononline.nl
Sat Sep 4 14:44:51 BST 2010
On 08/31/2010 11:00 PM, Evan wrote:
> Hi all.
> I've been following upstart development with half an eye for a while
> now, and one of the features that has always interested me the most is
> the plans for it to eventually replace cron/anacron/atd as the
> system-wide task scheduling tool.
I'm working on a construction to offer the user access to all kinds of
and remote, like usb, cdroms and samba shares.
It's using the at daemon as launch utility, and when I've got time, will
look for other "launchers" like upstart.
The reason is simple, it's using ConsoleKit for session support, and
udev for detection
Now, both (ConsoleKit and Udev) have the ability to execute scripts
(CK:/etc/ConsoleKit/run-session.d, udev: via a rules file with the RUN+=
command) but for both counts: when launching it will wait for the script
to finish, what is not good. Now I use at to run the script:
at -q "desired queue" -f "the script to run" NOW
This is very simple. I've written a script which can run a list of
command, after it first sorts it:
echo "firstscript" > "some file"
echo "another script" >> "some file"
export AT_COMMAND_LIST="some file"
at -q "desired queue" -f /etc/atd/generic.at.script NOW
This will run the commands firstscript and then another script.
At has many hidden features. You can make it reschedule commands,
and via the above construction wait first a certain amount of seconds, and
then run the second command.
It's also possible to make the generic.at.script look at the return value.
> I don't think there are pre-existing
> designs for this beyond what's listed on the FAQ (if there are, I
> couldn't find them with Google), so I gave it some thought myself.
> Here are a few options I came up with:
> My initial thought was to simply have upstart emit standard events
> every fixed period of time that jobs could hook into (ie 'starts on
> hourly'). However this runs into problems fairly quickly: it's not
> very flexible, it would be fairly complicated to add
> anacron-capabilities to it, and writing a job to start every x hours
> (x> 1) would require some uglyness in a pre-start script. While this
> would certainly work, it isn't great.
> My next thought was to have a config file somewhere
> (/etc/init-schedule.conf ?) where users could configure custom timed
> events. Upstart would read it, and know to emit event X every Tuesday,
> event Y every 3 hours, and event Z once a day. While this would be
> significantly cleaner than the previous solution, it still has one
> problem which I dislike - configuration for time-based jobs ends up in
> two different files. If I have job B that has a 'starts on
> B-schedule', the user then has to search through init-schedule
> separately to figure out when B-schedule is actually emitted. A better
> solution, but again not optimal.
> My third and final design is in many ways the farthest from the
> original 'everything by events' design of upstart, but I believe it
> most effectively replaces the existing cron/anacron/atd system.
> Upstart will designate a special event (like 'startup' is today)
> called 'schedule'. This event will have one parameter called 'job'. If
> schedule is referenced in a start or stop stanza without a specified
> job parameter, job=$self will be assumed for convenience. Each job
> file will have optional 'schedule' stanzas, similar in syntax to atd.
> Upstart will parse these stanzas, and when appropriate will emit a
> 'schedule job=x' event. For the user, anacron-like functionality will
> be available via the special-case schedule stanza 'schedule if
> missed', and atd-like functionality will be available via 'initctl
> There follows a very simple upstart job using this proposed syntax:
> start on schedule
> schedule every hour
> schedule if missed
> console output
> exec echo "This job runs like an hourly anacron job!"
> Of course these are only proposals - I'm not very familiar with the
> innards of upstart, so I'm sure I've made some false assumptions.
> However, I hope these will serve as starting-points for a proper
> design discussion. I'm quite familiar with C, and I've been looking
> for a place to give back to Ubuntu for a while now. If a design is
> decided upon for this feature, I'd be willing to spend some time
> implementing it.
> Evan Huus
More information about the upstart-devel