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....
Not sure how to show the process tree as shown above ...
"kill -s SIGCHLD" .. ran it against the PIDs of amrecover and pigz, no
effect.
pigz isn't even killed by a "-9"
-
I found a patch in the develop branch of the pigz github repo and
created an issue related to it:
https://github.com/madler/pigz/commit/9696c84cb1963651707e649978afb07d0c11b254
https://github.com/madler/pigz/issues/80
That patch is not included in the pigz-2.4 I have in debian.
So my plan is to maybe find (or receive ... someone motivated?) a beta
binary somewhere or compile it on some gentoo box maybe (I still have
some gentoo servers around).
Then test with that patched binary.
