@reboot and other cron fun. (tummy.com, ltd. Journal Entry)
tummy.com: we do linux

Sunday March 14, 2010 at 22:11
Subject: @reboot and other cron fun.
Keywords: cron, Technical
Posted by: Sean Reifschneider

swarren and I were just chatting and he mentioned putting something into rc.local. I said that I tended to prefer using "@reboot with cron" over rc.local these days. Partly because I don't like rc.local, partly because it keeps most of my system maintenance stuff in one place on my laptop. Stephen hadn't heard about @reboot though...

The cron daemon supports several "@ nicknames" for use instead of the normal set of time values: @reboot, and @hourly (daily, weekly, monthly, yearly/annually).

I use this in my personal crontab for a job I want run once at boot time:

   @reboot ~/bin/archivevimswap >/dev/null 2>&1

This is a small shell script that moves my ~/.vim-tmp out of the way and creates a new ~/.vim-tmp. I have vim configured to put all the tmp files in there, so that I don't end up with them littered all over the disc.

Just to be canonical, I'll mention that you can also be lists, ranges, and steps, so things like "*/5 * * * *" is every 5 minutes, "0 9-17 * * *" is the top of the hour from 9am to 5pm, and "15,20 * * * *" runs at 15 and 20 minutes past the hour.

Lately though, I've been thinking about what a next-generation cron would look like. It would be nice to say "I have these 10 jobs that need to be run between midnight and 4am, but I only want 3 of them running at once." Rather than having to try to stagger them. I could imagine a use for also having it "kill -STOP" jobs if the load goes above a certain value, or "kill -CONT" when it drops. Or even coordination among machines (I have 10 machines, they all need to run CPU-intensive jobs after midnight, but I don't want to cause a spike in power consumption or drop in responsiveness among all of them).

So many possibilities...
(Post Reply)

Comment
Author: Ken Weinert
Subject: Next Generation cron
cronq? IE, a queue of cron jobs with a controller that monitors load on the machine, pops a job off the queue and lets it run if the load is low enough to support it.

If a job is eating "too many" resources, throw it back on the queue for a while.

Since you have multiple machines that you want to have running the same jobs, perhaps a "master queue" where you could enter jobs that need to be run and each local machine grabs the job off the master queue and puts it on the local queue upon startup so you don't need to redundantly enter the same job on multiple boxes.