OK. I just ran this again hoping that an explicit set of the chunksize would
take care of this (ever optimistic) and just found this in the sendback
debug file:
sendbackup: debug 1 pid 12948 ruid 506 euid 506 start time Tue Sep 11
14:17:40 2
001
/usr/local/libexec/sendbackup: version 2.4.2p2
sendbackup: got input request: DUMP /data1 0 1970:1:1:0:0:0 OPTIONS
|;bsd-auth;c
ompress-best;no-record;index;
parsed request as: program `DUMP'
disk `/data1'
lev 0
since 1970:1:1:0:0:0
opt `|;bsd-auth;compress-best;no-record;index;'
sendbackup: try_socksize: send buffer size is 65536
sendbackup: stream_server: waiting for connection: 0.0.0.0.3111
sendbackup: stream_server: waiting for connection: 0.0.0.0.3112
sendbackup: stream_server: waiting for connection: 0.0.0.0.3113
waiting for connect on 3111, then 3112, then 3113
sendbackup: stream_accept: connection from 192.168.42.21.33137
sendbackup: stream_accept: connection from 192.168.42.21.33138
sendbackup: stream_accept: connection from 192.168.42.21.33139
got all connections
sendbackup: spawning /bin/gzip in pipeline
sendbackup: argument list: /bin/gzip --best
sendbackup-gnutar: pid 12949: /bin/gzip --best
sendbackup: spawning /sbin/dump in pipeline
sendbackup: argument list: dump 0sf 1048576 - /dev/hdb1
sendbackup: started index creator: "/sbin/restore -tvf - 2>&1 | sed -e '
s/^leaf[ ]*[0-9]*[ ]*\.//
t
/^dir[ ]/ {
s/^dir[ ]*[0-9]*[ ]*\.//
s%$%/%
t
}
d
'"
index tee cannot write [Broken pipe]
sendbackup: pid 12950 finish time Tue Sep 11 14:43:11 2001
Where does the tee come into play so I can tell what application failed? I
start by removing the compression.
markh
-----Original Message-----
From: John R. Jackson [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, September 12, 2001 3:16 PM
To: Mark Holm
Cc: '[EMAIL PROTECTED]'
Subject: Re: Need help figuring out why these don't complete
>I have not reset the chunksize from it's default so it is still at whatever
>the default is. I'll explicitly set it to 1Gb and try again. ...
The default is already 1 GByte, so that's not it (and you don't need
to change it). And I can see in the log you sent that it's still using
that value.
>Should it actually be -1Gb so that it forces a dump directly to tape?
Negative chunksize is no longer supported. But why would you want to
force direct to tape?
If you do want to force direct to tape, you could either add "holdingdisk
no" to your dumptypes (e.g. to "global") or set "use" to zero in the
holding disk.
>The amdump for the run detailed in my previous message is attached. I am
not
>sure how to decode this, but there does appear to be a REQ-MORE-DISK about
>the time it looks to fail.
Agreed, but I don't see any other clues. Any core files in /tmp/amanda?
>One question: Why does the rest of the dump fail if one of the running
>dumpers fail?
It wouldn't. But in your case, **all** of the running dumpers eventually
failed.
> markh
John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
