Re: Amrecover hangs after restore

Am 01.12.20 um 01:27 schrieb Nathan Stratton Treadway:
> On Mon, Nov 30, 2020 at 15:35:36 +0100, Stefan G. Weichinger wrote:
>> Am 30.11.20 um 00:40 schrieb Nathan Stratton Treadway:
>> https://github.com/madler/pigz/issues/80
> 
> As I mentioned before I'm not familiar with pigz myself, but skimming
> through those Github issues (76 and 80), I would guess that the problem
> you are having with amrecover is something unrelated to #76.
> 
> In particular, 76 seems to be about changing the exit status pigz
> returns if there is trailing junk on the compressed input stream... but
> as far as I understand at this point, there's no evidence of any
> trailing junk in the Amanda dumps.

The "evidence" is the error message happening while the amrecover 
process. I can't tell where it comes from, though.

> In any case, the problem doesn't seem to be amrecover mishandling some
> unexpected return status, but rather than it never retrivies the return
> status of the subprocess in the first place (as evidenced by the Zombie
> status of the pigz process).
> 
> Off hand I can't really say why that would the case, but one theory that
> comes to mind is the fact that gzip normally doesn't spawn it's own
> subprocesses but pigz does.  A way to test that theory would be put the
> shell-script wrapper around the pigz binary but just call the original
> binary with the same command line arguments that amrecover uses, and see
> if that setup ends up with processes in Zombie status as well -- and, if
> so, then try adding a "-p 1" parameter (for example) to the call to the
> real pigz binary to see if that changes the behavior any...

OK, I might try that in the next days or so.

thanks