Re: [help-gnubatch] ( [PATCH] Bump version in debian/changelog to 1.4 also ) + newbie question

[John M Collins]

On 06/06/12 01:10, Peter Valdemar Mørch wrote:
> Simple enough patch...
>
> Is there a searchable archive anywhere?
>
> Newbie questions about whether GNUBatch is for us:
>
> We're looking for a scheduler similar to the one built-in to nagios
> that allows us to run many small jobs where the scheduler takes care
> of determining when to actually run them, we just want to be
> guaranteed that they all get run at least every 15 minutes (as an
> example).  And that as jobs get added/removed, the scheduler
> automatically re-arranges the scheduling to smoothe out the load. I'd
> rather we didn't get into the specifics of "job 458 needs to run at
> 15:23:33", but more "these 1200 jobs all need to run every 15
> minutes".
>
> Other jobs are more "normal" and need to run exactly at specific
> times. These other "normal" jobs should not interfere with the "small
> job pool" above.
>
> We'd like later to be able to view the output ($? + stdout + stderr)
> of specific job runs, see when they started and examine how long they
> took. Because of the number of jobs, this info needs to expire /
> rotate / be deleted after some time.
>
> Is GNUBatch the tool for us? If so, how do we achieve the "small job
> pool"? I'm guessing with variables, but how?
>
> Also, I read in the GNUbatch reference manual, that "The time at which
> a job is scheduled to start can be specified by date and time to the
> nearest minute" :-( The lack of second-specific scheduling leads me
> towards "not for us" - is that a hard limit, can it be overcome
> somehow, or is it solvable by some "small job pool" pattern above?
>
> If GNUBatch isn't really for us, can anybody recommend something else
> given my outline above?
>
> Peter
>
It doesn't do seconds because when I wrote the original version back in
1990 you were lucky if you got minute-level accuracy from the machines
back then and seconds were not worth the effort of trying. Now it's
quite feasible to have second-level accuracy or even better.

It's amongst the many things I've got in the works for the next version
which I have mostly written but have been distracted by a lot of things
from finishing. I intend to start doing this before the end of the year.
My current task, after pushing through a load of changes I've just about
finished, is to rewrite the MS Windows Client interfaces. I'll then
restart the next version.

I don't think it would be that much of a sweat to change the existing
version for that I suppose the scheduling code will cope with that, it's
just the various interface tools that don't know about seconds.

So if you're prepared to hack the interfaces you can probably do what
you want. Or you can roll your own interfaces with the API. But wait
until I've pushed the current changes which impact on the API which I
intend to do as soon as I've finished testing them which I'm doing at
the moment - barring accidents by the end of the week with hopefully the
MS Windows Client interfaces by the end of the month.

John Collins