Hello Wolfgang,

Were you careful to change the actual volume retention period in
the catalog entry for the volume?  That requires a manual step after
changing the conf file.  You can check two ways:

1. Look at the full output from all the jobs and see if any
volumes were recycled while the batch of jobs ran.

2. Do a llist on all the volumes that were used during the
period the problem happened and see if they were freshly
recycled and that the retention period is set to your new
value.

If recycling is not involved, then this will be a *very* difficult
problem to solve because I have no way to reproduce it here.
In that case, there are only three ways out:

1. Hope that the new version to be released soon somehow
fixes the problem.

2. You or some other person figure out how to distill the problem
down to a test case that reproduces the problem and can be
given to me.  Once I have something that reproduces it, I can
fix it.

3. Hope that the problem shows up in the enterprise version,
because then I have a whole team of people who can work
with the customer to distill it down to a reproducible case that
can then be fixed.  Even that takes time. 

In any case, I will look over your previous emails to see if I see
anything that could point to a problem, and I will look at the bug
report, but without a test case, this is one of those "nightmare"
bugs that take huge resources and time to fix.

Best regards,
Kern

On 02/17/2014 09:45 AM, Wolfgang Denk wrote:
> Dear Kern,
>
> In message <20140216153143.2D773380410 AT gemini.denx DOT de> I wrote:
>>> I did find and fix was related to a user setting an expiration time of 
>>> exactly 1
>>> or n days, which means at some point when he started a whole batch of
>>> new backup jobs, a volume that was being used was recycled creating
>>> the race condition.  The solution is perhaps my patch, but it is much easier
>>> to set the expiration time to be slightly less than a multiple of a day 
>>> (e.g. 23 hours)
>>> then no volumes should expire while a lot of jobs are starting.
>> In my case I had "VolumeRetention = 18d" for all volumes in this pool;
>> I have changed this now to 455h (= 18d + 23h).  Let's see what
>> happens.
>>
>> Thanks for the hint; I will report results in a while (either when it
>> happens again nevertheless, or in a few weeks when it is sure that
>> this helped).
> We didn't have to wait long.  The error happened again last night, now
> with VolumeRetention set to 1,638,000 seconds = 455h = 18d + 23h.
>
> Seems this is another problem.
>
>
> Best regards,
>
> Wolfgang Denk
>


------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users