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.
