Adding second-level resolution to cron(8).

[Terry Lambert]

Rich Morin wrote:
> I have a project for which I need a generalized time-based scheduling
> daemon.  cron(8) is almost ideal, but it only has minute-level resolution.
> So, I'm thinking about modifying cron to add second-level resolution.
> 
> Before I start, I thought I'd ask a few questions:
> 
>    *  Has someone already done this?

There are a couple of programs that can do this, but they
aren't cron, per se.

>    *  Is it a Really Bad Idea for some reason?

One really bad thing about using cron as your starting point
is that each time it wakes up, it stats the crontab file to
see if it has changed (historical cron implementations needed
to be sent a SIGHUP instead).  It's also lazy about time
changes.

The net effect of the first is that it wildly spins updating
atime on the file; this is bad from a number of perspectives,
but the worst thing about it is that there ar a limited number
of duty cycles on things like flash memory "ATA" devices that
you would use in an embedded system, so you end up having to
do a lot of work to get a copy of the crontab into a ramdisk.

The net effect of the second is that cron would, in effect,
need to increase its rate of stat to once a second, which
means sixty time less MTBF, even if we are talking a disk inode
write, rather than a flash device.  Again, the fix would have
to be "move the crontab somewhere else".

Really, this type of thing needs a timer set to go off on or
after a spcific time, rather than using an interval timer, or
the code needs to get a lot smarter about calculating when the
next work needs to be done, and use a kqueue to watch the file
for modifications, instead, so it can use a select to implement
both the watching and the interval timer.  It also needs to be
smarter about not rereading the file every time it needs to run,
and using a cached copy instead.

Unfortunately, cron is not a happy program.  8-(.

-- Terry