Am 01.12.20 um 09:41 schrieb Stefan G. Weichinger:
Am 01.12.20 um 01:27 schrieb Nathan Stratton Treadway:
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.
I managed to find the time to write a small wrapper and do two
amdump-runs to holding disk only, one lev0, one lev1, then amrecover the
lev1 (to trigger reading 2 archives).
With the simple wrapper in place amrecover correctly runs through (*and*
pigz is used for the amdump and the amrecover step).
Tomorrow, when the admin there will insert a specific tape for me, I
will test that from the tape I used for the failing tests a few days ago.
