On Wednesday 23 June 2010 21:24:20 Robert LeBlanc wrote: > On Wed, Jun 23, 2010 at 1:17 PM, Kern Sibbald <k...@sibbald.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@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-users
