On Wednesday 23 June 2010 21:24:20 Robert LeBlanc wrote:
> On Wed, Jun 23, 2010 at 1:17 PM, Kern Sibbald <kern AT sibbald DOT com> wrote:
> > Yes, as Martin says, SIGUSR2 is something that should be ignored.  We use
> > it internally to signal between threads, and when you are running the
> > debugger on Bacula, you need to tell the debugger to ignore it -- as
> > Martin indicates, or most often, when I am manually debugging, I start it
> > with "run -s -f ...". For more information, see the Kaboom chapter of the
> > "Problems" manual.
> >
> > Of course, if Bacula sent you the traceback (or put it in your working
> > directory), you should open a bug report and post it there, and we will
> > look at it.
>
> I had to run gdb manually (the e-mail report kept coming back empty)
> and followed the notes in the manual. I did 'run -s -f ...' as the
> manual said. I'll ignore SIGUSR2 and get it to crash again.

Well, the -s should cause gdb to ignore the signal and just pass it to Bacula, 
which in turn ignores it.

If you are running Bacula 5.0.2, in 99% of the cases, you will find the 
traceback and the bactrace files in your working directory when Bacula is not 
run under the debugger and it crashes.

If you are running a 3.0.x or older version, you will need a support contract 
if you want us to look at the problem ...

Kern

------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Bacula-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users