>>>>> "Tilman" == Tilman Schmidt <[EMAIL PROTECTED]> writes:
Tilman> Andrzej Zawadzki schrieb: >> Tilman Schmidt pisze: >>> Andrzej Zawadzki schrieb: >> [...] >>> How to avoid that in the future? I have put that question to the list >>> once already. The only answer was to run jobs that might require >>> operator intervention (read: any backup job) only at times when an >>> operator is present (read: not on weekends or holidays). IOW: Bacula >>> doesn't like waiting. :-) >> That's my question ;-) How to avoid such deadlocks? >> Maybe bacula need something like "group of jobs" >> So, in my case I will have Group "Full" and last one will be my >> Tape-Eject and even lower priority then next Job, Tape-Eject job belongs >> to Group Full and must finished before Next Group. Tilman> I think a better solution would be an option not to queue the Tilman> same job more than once, ie. if the previous instance of a Tilman> scheduled job is still active or waiting when the next Tilman> scheduled time arrives, do not queue a second (third, ...) Tilman> instance. IMHO this should even be the default behaviour. I Tilman> cannot think of a scenario where it makes sense to run a job Tilman> again immediately after its previous run took longer than its Tilman> scheduling interval to complete. I agree! I'd like to see the option of just cancelling duplicate jobs (or not even scheduling them) if the previous one is still running. John ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ Bacula-users mailing list Bacula-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
