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