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
