Bacula-users

Re: [Bacula-users] Fatal error: askdir.c:340 NULL Volume name. This shouldn't happen!!!

2014-02-16 10:37:58
Subject: Re: [Bacula-users] Fatal error: askdir.c:340 NULL Volume name. This shouldn't happen!!!
From: Wolfgang Denk <wd AT denx DOT de>
To: Kern Sibbald <kern AT sibbald DOT com>
Date: Sun, 16 Feb 2014 16:31:43 +0100
Dear Kern,

In message <52FE44C5.8080704 AT sibbald DOT com> you wrote:
> 
> 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.

I have to admit that the status of the community version is not
exactly inspiring confidence.  But thisis another topic...

> 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 see this problem happening quite often.  On average it happens about
twice per week, with about 30 jobs running per day.  I think it is
worth noting that it is always exactly 2 jobs out of that batch which
fail, when are all started at the same time with the same priority.
But I cannot see anything special with these two configurations
compared to the rest.

> 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).

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd AT denx DOT de
A failure will not appear until a unit has passed final inspection.

------------------------------------------------------------------------------
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