On Fri, 24 Apr 2009, Silver Salonen wrote:
> In Bacula 2.x I used to use my own script that I ran in dir before every job.
> The script would query dir whether the job is already ran (the job may be
> still waiting for smth or running) and if this is the case, the script would
> return 1 and can
Well, I've got "Maximum Concurrent Jobs = 3", so it looks like the duplicate
job control does quite the same as "Maximum Concurrent Jobs = 1", which is
weird enough :)
PS. I haven't tried or tested this more, so maybe we're missing smth.
--
Silver
On Monday 04 May 2009 20:44:22 Stephen Thomps
That's the behaviour I've seen when I set Maximum Concurrent Jobs = 1
under JobDefs. Then only one job with the same name can run at a time.
What I was hoping for with duplicate job control was for the subsequent
job(s) to be canceled so that they wouldn't run at all.
thanks,
Stephen
Silv
Hello.
I noticed one thing today.. a big full backup was ran on friday, so it wasn't
completed 24 hours later, but when the next job's time arrived, it wasn't run.
I was very surprised, because I expected it to run as it has been the case
without "allow duplicate jobs = no" with Bacula 2.x. Whe
Hello.
In Bacula 2.x I used to use my own script that I ran in dir before every job.
The script would query dir whether the job is already ran (the job may be
still waiting for smth or running) and if this is the case, the script would
return 1 and cancel the job.
I hoped that would be the cas
