Hello,
If you were not aware, one developer left Bacula. He had previously
be the most active on bugs and responsible for putting patches into
the community version. As you probably also heard as a result of his
departure, I froze the git repository, and development has been continuing
at a very nice pace to the point that we should have a major new
release in late March or April. However, in between time there is no
developer
"devoted" to answering the bugs database, and I haven't found one yet. It
probably would not have helped much while the git repo was frozen anyway.
So, once we get a bit further in the flowback (backporting from Bacula
Enterprise
to the community), we will take a more careful look at the bugs. The
flowback
is not a new thing, we have been doing it since 2008 when Bacula Systems
started up. The last one was done just before the February 2013 release.
I am hoping that a number of the existing bugs have been resolved during
the freeze, but have not had the time to look in detail. The particular
case in point
askdir.c:340 from Patti's comments seems to be related to a very complicated
race condition that I have been "chasing" for months and recently found what
I think is the solution. This is one of those cases where we cannot
reproduce
the problem, so it is very hard to fix. In any case, we will see if
this code fixes the
problem -- it will be in the next community version. The particular
problem that
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.
I hope that helps.
Best regards,
Kern
On 02/13/2014 10:11 PM, Wolfgang Denk wrote:
> Dear Patricia,
>
> In message <CF228982.6EB06%clarkpa AT ornl DOT gov> you wrote:
>> I posted a similar notice 10/31/2013. Beyond the no responses, there is
>> no bug report which means no fix is pending. ...
> Thanks for the confirmation. It's somewhat reassuring to know others
> see this phenomenon, too.
>
>> ... Signing up to make a bug
>> report is also broken and has been mentioned on this list. No message is
>> sent that allows for verification and setting up an account.
> Confirmed, too. I even mailed Kern about this, but received no
> response either.
>
> Is there still anybody listening to bug reports in the free version of
> Bacula, or is this totally unsupported by now?
>
> Kern?
>
>> I can suggest a work-around that reduces the incidence of tape stealing by
>> the storage director from one job for another - set their job schedules
>> with an offset. I have used a 15 minute offset for jobs that had started
>> at the same time. I still have the "NULL Volume name" happening, but with
>> less frequency. I just look for it and rerun the affected jobs. My
> Yes, re-running is what I do so far, too, but it's a pain in the neck
> when the whole thing is supposed to run basically unmaintained.
>
>> current biggest issue is that the storage daemon doesn't see the job
>> failure and release the tape resource unless I restart the bacula
>> processes. There appears to be a bug report and a fix pending release for
>> that issue.
> Hm... Haven't seen this here yet.
>
> Thanks!
>
> 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
|
