On Tue, Aug 10, 2010 at 9:17 PM, G W Cantello
wrote:
> that did it,
> Thanks for the super fast reply.
Sure thing. I'm sorry the fix didn't make it into 3.1.2. I should
check on the progress of those packages...
Did this fix the underlying problem, or just the patch-not-applying problem?
Dust
On Tue, Aug 10, 2010 at 8:49 PM, G W Cantello
wrote:
> I presume it is my ignorance in using the GPATCH command.
No - rather, the patch is against trunk. Oops! I've rebased it onto
the 3_1 branch for you. Sorry about that!
You should be good to go, now. Use the same URL.
Dustin
--
Open So
On Sat, Aug 7, 2010 at 7:14 AM, Sean Walmsley
wrote:
> But, if I use the gtar '--ignore-zeros' flag (exists in 1.17
> as well as 1.22/1.23) then all versions keep running forever.
>
> We're compiling (and running) amcheckdump on a machine with
> gtar version 1.22, so perhaps that's the issue?
>
>
Hmmm - you may have something in the behaviour of gtar.
Using:
cat /dev/zero | gtar -tf -
gives:
GTAR ORIGIN VERSION RESULT
-- --- -
/usr/sfw/bin/gtar Sol10 U8 1.17runs forever
/usr/sfw/bin/
On Thu, Aug 5, 2010 at 2:57 PM, Sean Walmsley
wrote:
> It looks to me like:
>
> - process 10344 (amcheckdump) creates a pipe
> with file descriptors 8 and 9 at each end.
> - the process forks off a child (10350)
> - the parent closes fd8
> - the child closes fd9 and eventually dups
> fd8
Dustin:
We're using "amgtar" to dump, so I believe that amgtar is
also used for the validation. At some point amgtar calls
gtar.
I've done the 'truss' on amcheckdump and will send a much
reduced version as a .zip file attachment in a follow-up
email. The truss output covers the period in time bet
On Mon, Aug 2, 2010 at 12:56 AM, Sean Walmsley
wrote:
> Since this error is coming from just a few lines after the line
> that caused the hanging problem, and since amcheckdump should only
> be writing to the /dev/null device that wasn't being opened properly
> before, we thought that the problems
It's the weirdest thing, but many of Amanda's best bugs (in the sense
of being the most complex) are discovered independently by 3-4 people
within a week of one another.
Stephen Gelman, building Amanda on Nextenta, discovered the same bug.
What's happening is that amfetchdump is using the wrong sy
Dustin:
Your fix did solve our "hanging" problem - thanks!
As usual, one thing leads to another...
We're now seeing "broken pipe" messages like the following
from the amcheckdump process:
Validating image merlin:/etc datestamp 20100731124607 level 1 part 1/1 on tape
HBK1_14 file #1
Image was n
We're having problems getting amcheckdump (Amanda 3.1.1) to run
on Solaris 10 x86.
Amanda itself seems to run fine and tells us it's writing ~600Gb
a night to tape. We've checked this by repeatedly running
"dd if=/dev/rmt/0n bs=32k skip=1 | gtar -tf -" to step through
the tape contents and they lo
10 matches
Mail list logo
