On Wed, May 25, 2022 at 17:09:22 +0200, Stefan G. Weichinger wrote:
>
> So to me it looks that my dumptype with both compression and
> encryption is the problem.
>
> I use the script provided by Anton "exuvo" Olsson, he shared it in
> earlier threads here.
>
> The current iteration on this server:
>
> https://dpaste.org/2YrkJ
>
> Maybe it hasn't yet been tested with amrecover from multiple tapes?
>
> Or the combination with gzip is a problem.
I haven't used encryption with Amanda so I don't have anything
specific to suggest.
Off hand I don't see anything obviously incorrect with that script....
(Well... in the encrypt-operation case it writes the contents of "$@" to
/tmp/encryptparams file but that file doesn't ever appear to be
referenced... but that parameters don't appear to be referenced in the
decrypt-operation case either, so I don't expect that aspect of the
script is related to your problem.)
My next step would be to investigate the status of the subprocesses
during the period where amrecover seems to be hung, i.e. using ps, lsof,
and strace.
I'm guessing the "openssl enc -d" process doesn't exit for some reason;
can you identify what it's trying to do or waiting for? If you see that
process out there but just sleeping (i.e. using no CPU, and strace shows
it's just stuck waiting in a "read" syscall or something)), what happens
if you manually kill the process (i.e. does amrecover the proceed to
its next step)?
Nathan
----------------------------------------------------------------------------
Nathan Stratton Treadway - natha...@ontko.com - Mid-Atlantic region
Ray Ontko & Co. - Software consulting services - http://www.ontko.com/
GPG Key: http://www.ontko.com/~nathanst/gpg_key.txt ID: 1023D/ECFB6239
Key fingerprint = 6AD8 485E 20B9 5C71 231C 0C32 15F3 ADCD ECFB 6239
