Wish I knew why it fixed it. In fact, when I added the holding-disk stuff to disklist, it wasn't because I was trying to fix the index tee problem, per se, it was simply because I noticed I had forgotten it.
Then, subsequently noticed I had no more "broken tee" errors ... Regards, Michael Martinez ISTM/CSREES United States Department of Agriculture --- This email is signed with my digital signature so that you may verify the authenticity of the sender. --> -----Original Message----- --> From: Paul Bijnens [mailto:[EMAIL PROTECTED] --> Sent: Wednesday, November 05, 2003 10:19 AM --> To: Martinez, Michael --> Cc: [EMAIL PROTECTED] --> Subject: Re: sendbackup: index tee cannot write [Broken pipe], Why? --> --> --> Martinez, Michael wrote: --> --> > I had this problem and fixed it by specifying --> "holding-disk -1 local" in --> > disklist for the partition holding ~amanda on the tape server, and --> > specifying "-1 local" for the rest of the tape server partitions. --> > --> > --> John Grover wrote: --> > --> --> > --> > ? sendbackup: index tee cannot write [Broken pipe] --> > --> > ? index returned 1 --> > --> > sendbackup: error [/usr/bin/tar got signal 13] --> --> --> Clarifying -- I guess you had DLE's like: --> --> host.domain /amanda holding-disk -1 local --> host.domain / comp-user-tar -1 local --> host.domain /home comp-user-tar -1 local --> --> And with "comp-user-tar" instead of "holding-disk" on /amanda you --> would get the above error message. --> --> "Holding-disk" results in backup to tape immediatly, bypassing --> the holdingdisk. Any idea how that could influence the index tee? --> Did the ~amanda also contain the holdingdisk? If yes, then it's --> obvious you had to specify it, otherwise tar could create a huge --> (infinite) backup image. Eventually you would run out of --> holdingdisk --> space. --> --> Could it be triggered by the following sequence: --> Tar is reading some huge files, maybe compressing them too. This --> takes a long time; in the meanwhile the "index" tee times out --> in the server because the accompying index is only a few lines, and --> is still buffered in the client. But AFAIK there is no timeout --> on the index-tee, see dumper.c, line 1260 etc. --> Or there you should find some errors about "dup2", just --> before execlp --> the "gzip --best" for the index writer, or the gzip --best --> on the server crashed (how would you find out about this? there is --> no shell to log such a message). It could also be an output --> error in "gzip --best" because your disk got full. But then --> you should have found an message in the logs (or maybe not, because --> your disk was full :-) ). --> --> Just trying to understand -- maybe we found some obscure bug. --> --> --> -- --> Paul Bijnens, Xplanation Tel --> +32 16 397.511 --> Technologielaan 21 bus 2, B-3001 Leuven, BELGIUM Fax --> +32 16 397.512 --> http://www.xplanation.com/ email: --> [EMAIL PROTECTED] --> ************************************************************ --> *********** --> * I think I've got the hang of it now: exit, ^D, ^C, ^\, --> ^Z, ^Q, F6, * --> * quit, ZZ, :q, :q!, M-Z, ^X^C, logoff, logout, close, --> bye, /bye, * --> * stop, end, F3, ~., ^]c, +++ ATH, disconnect, halt, --> abort, hangup, * --> * PF4, F20, ^X^X, :D::D, KJOB, F14-f-e, F8-e, kill -1 $$, --> shutdown, * --> * kill -9 1, Alt-F4, Ctrl-Alt-Del, AltGr-NumLock, --> Stop-A, ... * --> * ... "Are you sure?" ... YES ... Phew ... I'm --> out * --> ************************************************************ --> *********** --> --> -->
smime.p7s
Description: S/MIME cryptographic signature
