Re: Amrecover hangs after restore
Nathan Stratton Treadway <[email protected]>
| Newsgroups | gmane.comp.archivers.amanda.user |
|---|---|
| Message-ID | <[email protected]> |
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. 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... Nathan ---------------------------------------------------------------------------- Nathan Stratton Treadway - [email protected] - 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