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....
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
