Re: Data Timeout

Ok, so I thought this might be a RAM issue so I upgraded the RAM to 4GB, didn't help. amcheck runs fine with no errors. I don't believe that this is a network issue because this machine is really just backing itself up; backing up 1 set of disks to another set of disks.
Inside one of the sendbackup logs (2 of them per night) I am seeing this...

index tee cannot write [Broken pipe]
sendbackup: time 3232.427: pid 12265 finish time Mon May 24 06:56:05 2004
sendbackup: time 3232.427: 126: strange(?): sendbackup: index tee cannot write [Broken pipe]

Could this be causing my problems? What is this? and why are my pipes broken?

I am attaching the full log below if anyone wants to see it.

sendbackup: debug 1 pid 12260 ruid 33 euid 33: start at Mon May 24 06:02:12 2004
/usr/lib/amanda/sendbackup: version 2.4.3
parsed request as: program `GNUTAR'
                     disk `/home'
                     device `/home'
                     level 1
                     since 2004:5:14:10:24:53
                     options `|;auth=bsd;compress-best;index;'
sendbackup: try_socksize: send buffer size is 65536
sendbackup: time 0.000: stream_server: waiting for connection: 0.0.0.0.32851
sendbackup: time 0.000: stream_server: waiting for connection: 0.0.0.0.32852
sendbackup: time 0.000: stream_server: waiting for connection: 0.0.0.0.32853
sendbackup: time 0.000: waiting for connect on 32851, then 32852, then 32853
sendbackup: time 0.001: stream_accept: connection from 192.168.1.6.32854
sendbackup: time 0.001: stream_accept: connection from 192.168.1.6.32855
sendbackup: time 0.001: stream_accept: connection from 192.168.1.6.32856
sendbackup: time 0.001: got all connections
sendbackup: time 0.001: spawning /usr/bin/gzip in pipeline
sendbackup: argument list: /usr/bin/gzip --best
sendbackup-gnutar: time 0.003: pid 12263: /usr/bin/gzip --best
sendbackup-gnutar: time 0.586: doing level 1 dump as listed-incremental from /var/lib/amanda/gnutar-lists/venus.berkeley-da.
com_home_0 to /var/lib/amanda/gnutar-lists/venus.berkeley-da.com_home_1.new
sendbackup-gnutar: time 0.593: doing level 1 dump from date: 2004-05-14 10:24:54 GMT
sendbackup: time 0.604: spawning /usr/lib/amanda/runtar in pipeline
sendbackup: argument list: gtar --create --file - --directory /home --one-file-system --listed-incremental /var/lib/amanda/g
nutar-lists/venus.berkeley-da.com_home_1.new --sparse --ignore-failed-read --totals .
sendbackup-gnutar: time 0.620: /usr/lib/amanda/runtar: pid 12269
sendbackup: time 0.620: started index creator: "/bin/tar -tf - 2>/dev/null | sed -e 's/^\.//'"
sendbackup: time 3232.427: index tee cannot write [Broken pipe]
sendbackup: time 3232.427: pid 12265 finish time Mon May 24 06:56:05 2004
sendbackup: time 3232.427: 126: strange(?): sendbackup: index tee cannot write [Broken pipe]

On Thu, 2004-05-20 at 05:21, Gene Heskett wrote:

On Wednesday 19 May 2004 17:48, Kris Vassallo wrote:
>AMANDA is starting to drive me nucking futs.. seems as if every week
>something new breaks and I can't find the answer to why.
>Here's whats going on... AMANDA sends me an email with the following
>information:
>
>These dumps were to tape DailySet118.
>The next tape Amanda expects to use is: a new tape.
>
>FAILURE AND STRANGE DUMP SUMMARY:
>  bda2.berke //illustrator/BDA_Manual lev 1 STRANGE
>  venus.berk /home lev 1 FAILED [data timeout]
>*SNIP*
>/-- venus.berk /home lev 1 FAILED [data timeout]

Please note it says "data timeout" here.

>sendbackup: start [venus.berkeley-da.com:/home level 1]
>sendbackup: info BACKUP=/bin/tar
>sendbackup: info RECOVER_CMD=/usr/bin/gzip -dc |/bin/tar -f... -
>sendbackup: info COMPRESS_SUFFIX=.gz
>sendbackup: info end
>
>Previously something else was broken and I set the etimeout a bit
>higher. I have now raised the etimeout to 10000 and it didn't fix
>anything. This backup was working last week and now all of a sudden
> it doesn't. It is trying to backup a 266GB file system and the disk
> that AMANDA is dumping to has 420GB available.  Any idea on what
> would be causing this?

You need to raise dtimeout in this case.  However, I'd investigate to 
see if a reason for the slowness of this client can be found.  My one 
client usually beats the server in the amount of time it takes. 

A bad NIC, hub/switch or cable maybe?  Something else hogging the 
bandwidth at that time of the night?