Amanda-Users

broken pipe (WAS: Re: timeout while waiting for REP)

2006-07-06 15:51:25
Subject: broken pipe (WAS: Re: timeout while waiting for REP)
From: Cameron Matheson <cameron.matheson AT fjcomm DOT com>
To: amanda-users AT amanda DOT org
Date: Thu, 6 Jul 2006 13:38:29 -0600
Hi, I'm back:

On Wed, Jul 05, 2006 at 04:56:43PM -0600, Cameron Matheson wrote:
> On Thu, Jul 06, 2006 at 12:36:43AM +0200, Peter Kunst wrote:
> > try using a larger number (in seconds) for "etimeout" in your amanda.conf
> > 
> > try "estimate server" within the dumptype used for that DLE (which is 
> > something new since, let me guess, can't remember, 2.5.x ?)
> 
> Thanks, I had never changed the default 300 seconds which is no where
> near long enough for this directory (I would need more like an hour).
> That estimate server thing looks like just the ticket too (spending an
> hour each night estimating would not be ideal).

Well, Changing the etimeout/estimate-method in amanda.conf definitely
helped, but now I'm getting a broken-pipe error.  Here's the excerpt
from this morning's e-mail:

  aspapp2.tonservices.com   /opt/webapp/images  lev 0  FAILED [data
  timeout]
  aspapp2.tonservices.com   /opt/webapp/images  lev 0  FAILED [dump to
  tape failed]

  taper: no split_diskbuffer specified: using fallback split size of 10240kb to 
buffer aspapp2.tonservices.com:/opt/webapp/images.0 in-memory
  taper: tape DailySet1012 kb 59249888 fm 25 [OK]

That looks bad... I looked up what split_diskbuffer was in the
amanda.conf manpage, but I'm not sure how setting that to anything
different would help me (I think I'll just let it use its default until
I understand it better).  Anyway, Here's the excerpt from the sendbackup
file on my client (Sorry, this is a little long):

sendbackup-gnutar: time 0.000: doing level 0 dump as listed-incremental
to
/usr/local/var/amanda/gnutar-lists/aspapp2.tonservices.com_opt_webapp_images_0.new
sendbackup-gnutar: time 0.076: doing level 0 dump from date: 1970-01-01
0:00:00 GMT
sendbackup: time 0.079: started index creator: "/bin/gtar -tf -
2>/dev/null | sed -e 's/^\.//'"
sendbackup: time 0.079: spawning /usr/local/libexec/runtar in pipeline
sendbackup: argument list: gtar --create --file - --directory
/opt/webapp/images --one-file-system --listed-incremental
/usr/local/var/amanda/gnutar-lists/aspapp2.tonservices.com_opt_webapp_images_0.new
--sparse --ignore-failed-read --totals .
sendbackup-gnutar: time 0.080: /usr/local/libexec/runtar: pid 15808
sendbackup: time 0.080: started backup
sendbackup: time 33267.859: index tee cannot write [Broken pipe]
sendbackup: time 33267.866: pid 15806 finish time Thu Jul  6 11:31:56
2006
sendbackup: time 33267.880: 117: strange(?): sendbackup: index tee
cannot write [Broken pipe]
sendbackup: time 33267.880: 117: strange(?): sed: couldn't flush stdout:
Broken pipe
sendbackup: time 33268.445:  46:    size(|): Total bytes written: 20480
(20KiB, ?/s)
sendbackup: time 33268.445: 117: strange(?): gtar: -: Cannot write:
Broken pipe
sendbackup: time 33268.445: 117: strange(?): gtar: Error is not
recoverable: exiting now
sendbackup: time 33268.633: error [/bin/gtar returned 2]
sendbackup: time 33268.633: pid 15804 finish time Thu Jul  6 11:31:57
2006

It takes 9 hours, so I can see why that might time-out, but I'm not sure
why the pipe is closed... isn't the output from tar going over the
network the entire time?  How do I prevent this from occurring?

Thanks again,
Cameron Matheson

<Prev in Thread] Current Thread [Next in Thread>