Bacula-users

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

2014-05-05 17:58:14
Subject: Re: [Bacula-users] Fatal error: askdir.c:340 NULL Volume name. This shouldn't happen!!!
From: Stephen Thompson <stephen AT seismo.berkeley DOT edu>
To: bacula-users AT lists.sourceforge DOT net
Date: Mon, 05 May 2014 14:53:37 -0700

Hello,

I believe this bug is present in version 7.0.3.

I just had it happen last night, much like I saw about 2 years ago.  I 
run 100s of incrementals each night across 2 LTO tap drives, running 
with a concurrency limit, so that jobs start whenever others are 
finished (i.e. I cannot stagger their start times.).  I'm assuming this 
is again a race condition, but one as an end-user I really cannot 
workaround.

So far the problem is not frequent, but does still appear to be an issue.

thanks,
Stephen




On 02/20/2014 09:30 AM, Kern Sibbald wrote:
> Hello Wolfgang,
>
> The drive is allocated first.  Your analysis is correct, but
> obviously something is wrong.  I don't think this is happening
> any more with the Enterprise version, so it will very likely
> be fixed in the next release as we will backport (or flowback)
> some rather massive changes we have made in the last
> during the "freeze" to the community version.
>
> If you want to see what is going on a little more, turn on
> a debug level in the SD of about 100.  Likewise you can set a debug
> level in the SD of say 1 or 2, then when you do a status,
> if Bacula is having difficulties reserving a drive, it will print
> out more detailed information on what is going on -- this last
> is most effective if jobs end up waiting because a resource
> (drive or volume) is not available.
>
> Best regards,
> Kern
>
> On 02/17/2014 11:54 PM, Wolfgang Denk wrote:
>> Dear Kern Sibbald,
>>
>> In message <5301DB23.6010109 AT sibbald DOT com> you wrote:
>>> 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:
>> Yes, I was. "list volumes" shows the new retention period for all
>> volumes.
>>
>>> 1. Look at the full output from all the jobs and see if any
>>> volumes were recycled while the batch of jobs ran.
>> Not in this run, and not in any of the last 15 or so before that.
>>
>>> 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.
>> retention period is as expected, no recycling happened.
>>
>>> 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.
>> Hm... I wonder why the DIR allocates for two simultaneous running jobs
>> two pairs of (DRIVE, VOLUME), but not using the volume currently
>> mounted in the respective drive, but in the other one.  I would
>> expect, that when a job starts, that either a volume or a drive is
>> selected first:
>>
>> - if the drive is selected first, and it has a tape loaded which is in
>>    the right pool, and in status append, then there should be no need
>>    to ask for any other tape.
>> - if the volume is allocated first, and it is already loaded in a
>>    suitable drive, then that drive should be used, ant not the other
>>    one.
>>
>> Best regards,
>>
>> Wolfgang Denk
>>
>
>
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
> _______________________________________________
> Bacula-users mailing list
> Bacula-users AT lists.sourceforge DOT net
> https://lists.sourceforge.net/lists/listinfo/bacula-users
>


-- 
Stephen Thompson               Berkeley Seismological Laboratory
stephen AT seismo.berkeley DOT edu    215 McCone Hall # 4760
510.664.9177 (phone)           University of California, Berkeley
510.643.5811 (fax)             Berkeley, CA 94720-4760

------------------------------------------------------------------------------
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
&#149; 3 signs your SCM is hindering your productivity
&#149; Requirements for releasing software faster
&#149; Expert tips and advice for migrating your SCM now
http://p.sf.net/sfu/perforce
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users

<Prev in Thread] Current Thread [Next in Thread>
  • Re: [Bacula-users] Fatal error: askdir.c:340 NULL Volume name. This shouldn't happen!!!, Stephen Thompson <=