[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Time & CmdSchedule
On Sun, 5 Dec 1999, Daniel E. Markle wrote:
> 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
But how does cron store state? Ie, how does it know how many time it has
already executed to know if it should run again?
> > 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 think it makes sense to just keep it all in there, because you don't
have the issues with trying to match db entries to crontab entries.
> > 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.
I get the impression that people don't understand what Jason and I have
planned. Here's the idea in a nutshell:
CmdSchedule.pl runs via cron every minute. It looks up what needs to be
run this time via the CmdSchedule table. The CmdSchedule table holds all
of the timing and repeating information for the command. Basically,
CmdSchedule.pl parses the 5 time to execute fields and determine if they
match the current time. If so it references the ExternalCommands table
for the command to run and forks it.
Anyways, the point it that there isn't that much manual coding to be done.
> > 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.
If cron had all the features of a DB then I'd be all for it. I just can't
think of a good way to manage the crontab file like a DB table. In this
case being able to do inserts and selects makes it easier than opening up
the crontab r/w and scanning it, trying to figure out which line is for
what. Even worse if someone ever goes in the crontab file and does a
manual edit.
> > 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.
Unfortunately it's in C and I'm writing in Perl. It should be much easier
to do in Perl :-). And no worries about doing the timing since cron will
handle that for us.
> 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.
It would be sucky to write a daemon to handle the timing, but that's what
cron is for. So far nobody has asked me to be able to run commands in
second intervals- yet. :-)
--
Aaron Turner, Core Developer http://vodka.linuxkb.org/~aturner/
Linux Knowledge Base Organization http://linuxkb.org/
Because world domination requires quality open documentation.
aka: aturner@vicinity.com, aturner@pobox.com, ion_beam_head@ashtech.net