I did the gdb thing, but it really didn't produce much info.  I used
the command line 

   gdb /usr/bin/perl5 70805

and after all of the 'loaded symbols' messages, I generated the
following output.

  [Switching to Thread 28469480 (LWP 100148)]
  0x28af6225 in __error () from /lib/libthr.so.3
  (gdb) info threads
  * 1 Thread 28469480 (LWP 100148)  0x28af6225 in __error ()
     from /lib/libthr.so.3


I then added some simple debugging messages to the taper perl script.

I just printed the subroutine's being called to STDERR so they would
show up in the amdump log file.  The following is the tail of that
file from the point where the taper should transferring the file to
my virtual tape.


  driver: send-cmd time 26.691 to taper: FILE-WRITE 00-00002 
/amanda/holding-b/20100918162652/galadriel.corbesero.net._.2 
galadriel.corbesero.net / 2 20100918162652 0 847
  SGC: main::Controller::_assert_in_state()
  SGC: main::Controller::setup_and_start_dump()
  SGC: main::Controller::_assert_in_state()
  SGC: main::Controller::get_splitting_config()
  driver: startaflush: FIRST galadriel.corbesero.net / 109 9216000
  driver: state time 26.699 free kps: 8000 space: 16256915 taper: writing 
idle-dumpers: 4 qlen tapeq: 0 runq: 0 roomq: 0 wakeup: 0 driver-idle: no-dumpers
  driver: interface-state time 26.699 if default: free 8000
  driver: hdisk-state time 26.699 hdisk 0: free 2129920 dumpers 0 hdisk 1: free 
14126995 dumpers 0

As you can guess, the SGC: lines are my trace outputs.  The end of
this amdump is the spot where taper just sits....

What should I look into next?  Should I add more debugging lines to
the taper script and the other taper modules?

 

  


On Mon, Sep 13, 2010 at 11:14:49PM -0500, Dustin J. Mitchell wrote:
> On Mon, Sep 13, 2010 at 8:30 PM, Stephen Corbesero <corbes...@ptd.net> wrote:
> > If I kill the taper process, everything shuts down "normally", but the
> > email says there was a taper protocol error and nothing was written.
> >
> > I turned on taper_debug in my amanda.conf, but that didn't seem to
> > produce any extra output. I have also snooped around various log
> > files, but I don't see any clues.
> 
> If you can run gdb or the equivalent on the "hung" taper process, and
> send the backtrace, that would be helpful.
> 
> You'll want to use the 'info threads' command in gdb to figure out
> what threads are active, and then the 'thread' command to switch to
> each one and the 'backtrace' command to generate a backtrace for it.
> 
> Dustin
> 
> -- 
> Open Source Storage Engineer
> http://www.zmanda.com

-- 
Stephen Corbesero                        It's always darkest 
Bethlehem, PA 18015                      before pitch black.
corbes...@ptd.net                        

Reply via email to