Bacula-users

Re: [Bacula-users] bacula-fd crashes on FreeBSD 9.2

2013-10-18 12:01:41
Subject: Re: [Bacula-users] bacula-fd crashes on FreeBSD 9.2
From: Martin Simmons <martin AT lispworks DOT com>
To: bacula-users AT lists.sourceforge DOT net
Date: Fri, 18 Oct 2013 16:58:29 +0100
>>>>> On Thu, 17 Oct 2013 16:29:22 -0700, David Newman said:
> 
> On 10/17/13 5:33 AM, Martin Simmons wrote:
> >>>>>> On Wed, 16 Oct 2013 12:13:26 -0700, David Newman said:
> >>
> >> On 10/14/13 2:44 AM, Martin Simmons wrote:
> >>>>>>>> On Sun, 13 Oct 2013 18:25:07 -0700, David Newman said:
> >>>>
> >>>> On 10/9/13 4:41 PM, David Newman wrote:
>>>>> FreeBSD 9.2-RELEASE, bacula-client-5.2.12_3 installed from ports
> >>>>>
>>>>> Ever since upgrading this host to FreeBSD 9.2, bacula-fd crashes as soon
>>>>> as bacula-dir starts a backup job. The entry in /var/log/messages is:
> >>>>>
>>>>> Oct  9 16:25:50 o bacula-fd: Bacula interrupted by signal 0: UNKNOWN 
>>>>> SIGNAL
> >>>>>
>>>>> Backups worked fine on this host running FreeBSD 9.1 and other hosts
>>>>> upgraded to FreeBSD 9.2 run backups OK.
> >>>>>
>>>>> I've done the uninstall/reinstall thing with the bacula-client port, but
>>>>> that made no difference.
> >>>>>
>>>>> Thanks in advance for troubleshooting clues.
> >>>>>
>>>>> dn
> >>>>
> >>>> Is there a Wireshark decode for Bacula?
> >>>>
> >>>> I'm still stuck on this problem, and need more info on what's causing
> >>>> that UNKNOWN SIGNAL error. Wireshark 1.8.6 just shows strings of bytes
> >>>> for the Bacula stuff.
> >>>>
> >>>> Thanks.
> >>>>
> >>>> dn
> >>>
> >>> A wireshark decode won't help much here because problems like this must 
> >>> be in
> >>> the fd itself.
> >>>
> >>> Try attaching gdb to the bacula-fd process and see if it catches the
> >>> mysterious signal (see
> >>> http://www.bacula.org/5.2.x-manuals/en/problems/problems/What_Do_When_Bacula.html#SECTION00640000000000000000).
> >>
> >> No luck with this. Per that URL, I've put the btraceback.gdb file in the
> >> same directory as the bacula-fd executable on the client (in this case,
> >> /usr/local/sbin) and made the .gdb file executable.
> >>
> >> At run time it produces this error:
> >>
> >> /usr/local/sbin/btraceback.gdb:1: Error in sourced command file:
> >> No symbol table is loaded.  Use the "file" command.
> >>
> >> That's problem 1. Problem 2 is that the syntax given for capturing
> >> STDERR and STDOUT -- 2>\&1 -- doesn't work on either csh (root's default
> >> on FreeBSD) or bash.
> >>
> >> Any ideas on remedying either issue?
> > 
> > It looks like you missed the part after the # in the URL -- you don't need 
> > the
> > btraceback.gdb file.
> > 
> > The section I meant is called "Manually Running Bacula Under The Debugger" 
> > on
> > that page (you'll have to adapt it for the bacula-fd).
> 
> Sorry for missing that.
> 
> The backup runs fine under the debugger, including the backup job
> beforehand, but not with the FreeBSD startup script in /usr/local/etc/rc.d.
> 
> I've pasted below the debugger output and the startup script.

OK, that looks like a normal idle bacula-fd.

Can you try attaching gdb to the bacula-fd process started by the startup
script?  Do this by running gdb and then use the attach command with the pid
of the bacula-fd process (instead of the run command).

__Martin

------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users