Ah, thanks for the info, but this still is not the behavior that I am
looking for. This does indeed cancel incrementals if a full is already
running (actually even if a full is merely scheduled), but it goes both
ways, it also cancels my fulls if an incremental is already running or
scheduled. It's the scheduled part that causes me problems. I have
incrementals scheduled to run every day. I then interject full jobs
each day based on a script that determines which of my hosts are
available for a full that day.
This configuration immediately cancels my fulls, rather than letting
them run and then canceling the corresponding incrementals when they are
actually launched. This might work out if all jobs have static (i.e.
based on configuration files) schedules, but rather than controlling
duplicates, it seems better at preventing administrator intervention
which is frustrating.
I recognize I might have a unique situation (dynamically scheduling
fulls based on availability rather than a regular calendar cycle) which
is fine; I'll probably have to pull my incremental scheduling out of
bacula and cron the injection of jobs via a script. But to me, there is
still a design issue with considering a scheduled job to be in duplicate
conflict with a running job; it seems like it would make more sense to
only apply that logic in the running queue (whether actually running or
waiting for resources). Then "canceled queued duplicates" would cancel
any job that attempted to enter the running state if another job was
already running. As it is now, it appears to cancel any job entering
the running state even if another job is merely scheduled to run at some
point in the future. Cancellations should happen on conflict, not on
suspicion that conflict might arise in the future.
But perhaps that's being too philosophical. :)
Stephen
Silver Salonen wrote:
> On Tuesday 15 September 2009 17:36:25 Stephen Thompson wrote:
>> Silver Salonen wrote:
>>> Actually, you can do it - "Allow Higher Duplicates" really means ANY
>>> duplicate job, not only a higher one. I just tested it and an incremental
>>> job is cancelled if either full or incremental instance of the same job
>>> is still running.
>>>
>>> So in my case "Allow Higher Duplicates" did the trick :)
>> Really?
>>
>> This is exactly what I want and what I tried for when 3.x was first
>> released, but my experiments showed that nothing was canceled. The jobs
>> rather began running concurrently.
>>
>> I'll try this again. Are you saying to set Allow Higher Duplicates to
>> Yes or No? Actually, could you possibly list what you have all the
>> relevant values set to? I would most appreciate it.
>>
>> thanks,
>> Stephen
>
> Yeah, I was positively surprised today too :)
>
> I have just one option in every JobDefs for that:
> Allow Higher Duplicates = no
>
--
Stephen Thompson Berkeley Seismological Laboratory
stephen AT seismo.berkeley DOT edu 215 McCone Hall # 4760
404.538.7077 (phone) University of California, Berkeley
510.643.5811 (fax) Berkeley, CA 94720-4760
------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users
|
