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
step...@seismo.berkeley.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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Reply via email to