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%clar...@ornl.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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
