> I hadn't planned to cancel the lower priority job, but I had thought about > the > possibility. However, now that you mention it, I think we need some > keyword > to do this. Any suggestions? -- CancelLower, HigherWithCancel ?
On further thought, perhaps the right thing to do would be to promote the running job to the higher level and skip initiating the new job (or initiate it, but exit immediately with a note that the job had been superceded by a promoted job). You'd probably have to go back and figure out if you'd missed anything. I hesitate to just cancel the job, because that would make it harder to determine whether a job was cancelled for some error or manual intervention, or whether it was cancelled due to competing job promotion. > By the way, if a lower priority job is scheduled, but not running, I was > planning to cancel it. A new keyword would certainly clarify what should > happen. Perhaps this syntax: Yes | Skip | Error | Promote Yes = Allow duplicate jobs to run simultaneously (default). Skip = Do not allow two or more jobs with the same name to run simultaneously within the proximity interval. The second and subsequent jobs are skipped without further processing (other than to note the job and exit immediately), and are not considered errors. Error = The second and subsequent jobs that attempt to run during the proximity interval are cancelled and treated as error-terminated jobs. Promote = If a job is running, and a second/subsequent job of higher level attempts to start, the running job is promoted to the higher level of processing using the resources already allocated, and the subsequent job is treated as in Skip above. > Another point is that I could do a lot of this in the scheduler -- i.e. > just > not run jobs if one was already running, but I think I will actually > "start" > the job, print a message, then cancel it if it is of equal or lower > priority > (i.e. not supposed to run). That way, there will be some record. We > might > even want to invent a new message class (for example: AutoCancelled) so > that > the job output from such jobs could be sent elsewhere (i.e. down the bit > bucket if one wants). Seems reasonable. See the above discussion on treatment of the difference between cancel with no error, and cancel as error, and promoting the running job to do additional processing. The existing message classes are fine, IMHO. It's probably more a job status than a message class. ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
