> On Nov 25, 2020, at 3:30 PM, Stefan G. Weichinger <[email protected]> wrote:
>
> Am 25.11.20 um 20:57 schrieb Nathan Stratton Treadway:
>> On Wed, Nov 25, 2020 at 14:34:17 -0500, Nathan Stratton Treadway wrote:
>>> Also, do you see the same defunct pigz process that Jason reported in
>>> his original post?
>>
>> Am 30.05.18 um 20:21 schrieb Jason L Tibbitts III:
>>> root 2690 9.1 0.0 317692 11020 pts/0 S+ 12:38 1:43 |
>>> \_ amrecover math -s backup2 -t backup2
>>> root 2996 32.5 0.0 0 0 pts/0 Z+ 12:48 2:52 |
>>> \_ [pigz] <defunct>
>>> root 2998 3.3 0.0 0 0 pts/0 Z+ 12:48 0:17 |
>>> \_ [xfsrestore] <defunct>
>>
>> Assuming you are seeing this same behavior: one theory that comes to
>> mind is that pigz could be spawning subprocesses which then somehow
>> confuse amrecover such that it doesn't properly detect when pigz
>> terminates (and just keeps waiting for that to happen, even though it
>> already has happened).
>>
>> I don't know enough about how amrecover spawn the pipes to know how
>> likely that is, but one thing you could try is to kill the amrecover
>> process with a SIGCHLD signal (once it reaches the above "everything is
>> hung" situation) and see if one or both of those defunct processes go
>> away, and if the amrecover process starts doing work again
>> afterwards....
>
> short reply, as it is late here already:
>
> the theory is good, sure. I will test the restore aside from amrecover
> tomorrow.
If so, remember to “throw out” the first block of the file, which will choke
the zip program.
dd -skip=1 etc
Deb Baddorf
