> On Thu, 28 May 2020 06:10:36 +0100, Bernie Elbourn said:
>
> On 01/04/2020 16:10, Bernie Elbourn wrote:
> > Oddly, jobs run sequentially as follows rather than duplicates being
> > cancelled:
> >
> > Running Jobs:
> > Console connected at 29-Mar-20 12:36
> > JobId Type Level Files Bytes Name Status
> > ==
> > 70172 Back Diff 120 36.70 M Backup-pc is running
> > 70173 Back Incr 0 0 Backup-pc is waiting on max Job jobs
> >
> >
> > Are there any pointers to trace why the duplicate job 70173 is not
> > cancelled?
>
> So I have cloned the system (less backup volumes) to test system with a test
> pc. That test system has exactly the same
> database and same bacula sever and same pc setup.
>
> On the test system the second incremental job IS cancelled. The reason is
> pretty clear
>
> 12-May 15:35 sv-dir JobId 71204: Fatal error: JobId 71202 already running.
> Duplicate job not allowed.
>
> Is there any logging or tracing information available on an actual live
> system that might reveal why the production
> bacula system decides to wait on max job jobs?
There is no useful logging for this, but the function that checks for
duplicates is allow_duplicate_job in src/dird/job.c. You could either add
some more logging to it or run the Director under gdb and step through it.
__Martin
___
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users