On Friday 22 February 2008 15.44:56 Bastian Friedrich wrote:
> Hi,
>
> On Wednesday 20 February 2008, Bastian Friedrich wrote:
> > when configuring multiple "Run"s in a schedule that occur at the same
> > time, they are run sequentially:
> > Run = Full Pool = PoolSpecial w01 mon at 8:00
> > Run = Full Pool = Pool mon at 8:00
> > results in two executions of the job that refers to the schedule.
>
> [...]
>
> > I'd have a need for exclusiveness in this case: run the job only in case
> > it is not referenced before. Would you also regard this as a sensible
> > modification?
>
> despite the fact that we found workarounds during our discussion (on
> bacula-users), I wrote a small patch:
>
> With the attached patch, Schedule statements can include an
> optional "QueueOnce" flag (i.e. QueueOnce=true, with QueueOnce=false being
> default). If this flag is set, a job will only be queued once per minute.
> With this enabled, one can e.g. schedule a job "first of month" as well
> as "mondays"; the job will only be queued once if a monday is a first of a
> month as well, and both events were queued for the same minute.
>
> This modifies the current behavior, where jobs were queued twice.
>
> Because of Bacula's internal logic, the _last_ "Run" statement in a
> schedule wins; we can understand this as "overwriting" statements.
>
> What do you think about this idea/code?
Well, I like the idea (the feature), but I'm a little concerned about the
solution you propose from several stand points:
1. I found it hard to understand what you wanted to do until I read the code,
so I am concerned that this concept could be hard to document correctly.
2. The current list of Run directives are essentially ANDed. That is Bacula
will walk down the list and schedule all that apply. I think what you really
are trying to do is to setup two Run directives to be ORed, and perhaps that
could be handled by a slightly different syntax such as:
Or {
Run = Level=Full Pool = PoolSpecial w01 mon at 8:00
Run = Level=Full Pool = Pool mon at 8:00
}
or perhaps some other keyword such as OneOf ... wouldn't that be much
clearer?
There would be a bit more work to implement this (not really hard) but
it seems to me it would be much clearer to the user.
3. It is interesting that this comes just at this moment, because just tonight
I was starting to work on the new "Duplicate Jobs" directive group for Jobs.
That is a fairly comprehensive set of directives that tell Bacula how to deal
with duplicate jobs. This too could also be a solution to the problem
somewhat like #1, but much less elegant or explict than my proposal #2.
That is if you do not allow duplicate jobs of the same level, using the
current syntax, you could put both Run statements, and if a second one
started, it would simply be killed -- a bit kludgie, but it would work
nicely.
Comments?
Best regards,
Kern
>
> Oh, btw: the attached patch is against SVN trunk.
>
> Thx, Best regards,
> Bastian
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users
