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?
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. While I'm at it, what should bacula do if it starts up and discovers jobs whose execution time has passed? 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. 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. ------------------------------------------------------- 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
