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?
<<attachment: smiley-3.png>>