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.
I think a better solution would be an option not to queue the same job more than once, ie. if the previous instance of a scheduled job is still active or waiting when the next scheduled time arrives, do not queue a second (third, ...) instance. IMHO this should even be the default behaviour. I cannot think of a scenario where it makes sense to run a job again immediately after its previous run took longer than its scheduling interval to complete. -- Tilman Schmidt Phoenix Software GmbH www.phoenixsoftware.de 53227 Bonn, Germany Amtsgericht Bonn HRB 2934
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------- 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
