On Friday 25 November 2005 20:02, Ross Boylan wrote:
> On Fri, Nov 25, 2005 at 07:27:28PM +0100, Kern Sibbald wrote:
> > On Friday 25 November 2005 19:18, Ross Boylan wrote:
> > > Apparently it is not possible to cancel scheduled jobs, those without
> > > a jobid.  I think it would be useful to do so.
> > >
> > > There may be other operations on scheduled jobs that are not possible
> > > but would be desirable.  Can anyone think of any?
> > >
> > > I recall needing this feature for two reasons.  First, I somehow got
> > > duplicate jobs scheduled, maybe beacause I did a reload.  Second, my
> > > system was off during one of the scheduled backups, and the scheduled
> > > jobs hung around for awhile afterwards, though they didn't run.  This
> > > second issue is only significanct because it produces visual clutter,
> > > I believe.  The first one actually produces extra backup jobs.
> > >
> > > Given my relative unfamiliarity with bacula, I'm throwing this out for
> > > discussion rather than jumping straight to a formal proposal.
> >
> > I think this would be a desirable feature.  However, it is a non-trivial
> > project and would require a major rewrite of the scheduler, which is
> > perhaps not a bad idea ...
>
> Can anyone describe the scenarios under which jobs get scheduled or
> removed from the schedule?  I'm not totally sure about the second one
> listed above: is it true that doing a reload can make duplicate jobs?
> Does it only do so if some of the parameters change?

Technically, there are two schedulers.  The first scheduler looks at the 
schedules the user has defined, and when the appropriate time occurs, the job 
is run.  This is the scheduler where jobs cannot be cancelled.

Then there is a second job scheduler that holds jobs until their resources are 
available (i.e. enough concurrent job slots to run them).  These jobs are 
actually running even though they are being held, and they can be cancelled.

>
> On deletion of scheduled jobs, I think shutting down the system and
> restarting it will suffice.  Also, maybe old jobs get canned after a
> certain time?  Again, I'm not sure what did it for me.

Well, here we need to get the terminology straight, because with the first 
scheduler, there is no job; there are only times in the future when a job 
will be created (or run). When a job is deleted, it is removed from the 
database, so delete is not a term to use in this Bacula context. The 
scheduling of a job could be skipped (perhaps the user would like to consider 
this canceling, that is OK).

>
> While I'm at it, what should bacula do if it starts up and discovers
> jobs whose execution time has passed? 

This cannot happen unless the clock skips time since the job will be 
immediately started at the scheduled time.  Once a job is started and it is 
running, it can get blocked.  There is a directive where you can control how 
much time you want it to wait, then the job will be cancelled.  Otherwise, 
the job is unblocked when it can be.

> The behavior I observed was 
> that they just sat there.  I think running them might be more
> appropriate, although I realize this is installation dependent.  That
> is, backups may have been scheduled for a certain window either for
> the backups benefit (system in quiet state->reliable backups and
> faster backups) or users (don't want backups interefering with
> production).  So such an installation would want a job skipped if its
> time had passed.

That already exists.

>
> Possibly, jobs could have a run no later than parameter to resolve
> this ambiguity.  I seem to have wandered onto a separate feature ....
>
> Then there's the longstanding issue of what to do about clocks jumping
> ahead or behind, which seems it could result in either duplicate jobs
> or no jobs.  But there's already a bug on that, and as noted in the
> bug it's difficult to see how to solve this problem.

That is a separate problem that I will fix when I know how ...

-- 
Best regards,

Kern

  (">
  /\
  V_V


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Bacula-users mailing list
Bacula-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bacula-users

Reply via email to