[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Bacula-devel] Patch: Status Command Changes The Job Type
This patch looks perfectly good to me -- you have even nicely optimized the
I have now applied it to the trunk (to be committed today), and will probably
commit it to Branch-2.2 so that it will appear in version 2.2.10-b4 and
Thanks for the contribution,
On Wednesday 21 May 2008 16:03:00 Allan Black wrote:
> This has been discussed a few times. My original email is below.
> In a nutshell: if a "status director" command is issued using the
> console AND there is at least one scheduled job reported, then the
> console session will cause num_jobs_run to be incremented when the
> console disconnects.
> The attached patch (which I have been running live now for several
> weeks, and also passes the regression tests against trunk) fixes
> this. I had to implement option (1) from my original email. (2) did
> not work at all, for various reasons.
> The patch does 2 things:
> 1) Saves and restores the console JCR's job type
> 2) Only increments num_jobs_run if jcr->JobId > 0
> -------- Original Message --------
> Subject: Status Command Changes The Job Type
> Date: Wed, 13 Feb 2008 20:23:21 +0000
> From: Allan Black <Allan.Black@xxxxxxxxxxxxx>
> To: bacula-devel@xxxxxxxxxxxxxxxxxxxxx
> Just had a look at ua_status.c, because of something which
> has been annoying me for a while.
> If there are any scheduled jobs, the "st dir" command causes
> num_jobs_run to be incremented when the console disconnects.
> [ I noticed this while I was testing a script, and could not
> understand why the "jobs run since started" kept increasing
> every time I ran it ]
> What is happening is this:
> The console's JCR starts off with its JobType set to JT_ADMIN.
> The list_scheduled_jobs() function calls prt_runtime() on any
> jobs in the sched list. prt_runtime re-uses the console's JCR
> to emulate the job which is being examined, and to do so, it
> has to change some of the JCR's values.
> In particular, prt_runtime() calls complete_jcr_for_job(),
> which in turn calls set_jcr_defaults(), which sets the JCR's
> JobType to be the Job's JobType, i.e. JT_BACKUP.
> prt_runtime() restores the JCR's db field to its original
> value (which is in the UAContext), but not any of the other
> As a result, when the console disconnects, the director frees
> the JCR and increments num_jobs_run, because jcr->JobType is
> set to JT_BACKUP.
> This is a trivial bug, but of more concern to me is the fact
> that the console's JCR has been 'corrupted'.
> I would like to fix this, but would appreciate your opinions
> on the correct way to go about it:
> 1) Restore the JobType to the correct value at the end of
> prt_runtime(), either by saving it, or by explicitly
> setting it to JT_ADMIN (I would probably prefer to
> save/restore, just in case).
> 2) Create and destroy a new JCR object in prt_runtime()
> instead of re-using the console's JCR.
> I think 2 is technically the correct way to do it, since
> there may be other fields in the JCR which are changed, but
> it may be more difficult.
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
Bacula-devel mailing list
This mailing list archive is a service of Copilotco.