Re: Time & CmdSchedule

["Daniel E. Markle" <syntax@ashtech.net>]

On Fri, Dec 03, 1999 at 02:47:23PM -0800, Aaron Turner wrote:
> Repeat X times then disable.
> dynamic email address to send output/errors to
> Ability to run reports (failures, sucesses, etc)

These are all just a matter of passing stuff to your script, like:

* * * * * CmdSchedule --repeat 3 --email "syntax@pa.net,jpincin@linuxkb.org,aturner@linuxkb.org" --reportonfail

> Keeping track of cronjobs will require a DB to keep track of what's in the
> crontab file anyways or you have to do some "horrible" hack with comments:
> * * * * * <do something> # comments here 

You're right, a system to keep track of this stuff would need to be made.  Of
course it needs to be made anyway no matter how you do it.

> I don't think writing this script is very difficult, and there are some

This is what my discussion was all about, it sounded to me like writing this
thing manually was going to be a time consuming nightmare.

> Actually writing the scripts to maintain the crontab file would be more
> complicated than maintaing the DB table.  you've got file locking issues,

Ok.  If writing the timing code is easy, I'm all for it.  There are a lot of
pitfalls though, that cron avoids for you, that you won't want to miss.

> crontab.  The only "hard" part of the DB way is writing a time/date parser
> to support the / and - and , operators.  I'd rather do that IMHO.

Is this code you can just rip out of the cron code?  It is GPLed, and our code
is going to be too.  Perhaps you can get timing handling code from there too.

I looked for a DB based cron as well, and didn't find anything.  So your flat
file concerns concern me too.  I do think a measly 100 or even 1000 crontabs
don't bug cron, but we will hit a number that does eventually.  We can get
around this by using fixed common timings for our scripts instead if we need
to.

I'm not sure you got the drift of what I was getting at, I was never saying we
could just use cron, we would need wrapper scripts.  I was just assuming the
timing code would be really sucky to rewrite, if it isn't, my ideas are quite
useless.

-- 
-------------------
Daniel E. Markle
syntax@ashtech.net
http://www.ashtech.net/syntax
-------------------