[Top] [All Lists]

Re: [PATCH] xfsdump: allow system() to obtain exit status

To: Bill Kendall <wkendall@xxxxxxx>
Subject: Re: [PATCH] xfsdump: allow system() to obtain exit status
From: Dave Chinner <david@xxxxxxxxxxxxx>
Date: Thu, 12 Jan 2012 09:20:36 +1100
Cc: xfs@xxxxxxxxxxx
In-reply-to: <1326316073-15033-1-git-send-email-wkendall@xxxxxxx>
References: <CAGdb-8fyseE+ARMUWaQYcx1VCnmph=xL7XeTBUXg2wSSdF_7hw@xxxxxxxxxxxxxx> <1326316073-15033-1-git-send-email-wkendall@xxxxxxx>
User-agent: Mutt/1.5.21 (2010-09-15)
On Wed, Jan 11, 2012 at 03:07:53PM -0600, Bill Kendall wrote:
> xfsdump explicitly ignores SIGCHLD in order to prevent librmt rsh
> processes from becoming zombies. However, doing so interferes with the
> ability for system() to determine a command's exit status.
> Setting up a handler for SIGCHLD will not work either, since xfsdump is
> now multi-threaded and the main thread (which handles signals) might
> handle a child exit before the thread running system() can.
> I also attempted to use waitpid() when tearing down a librmt session,
> but this has the potential to block indefinitely if there is a problem
> on the remote side. (And using WNOHANG tended to never catch the exit.)
> In the end, I settled on just not touching SIGCHLD at all. There may be
> a zombie rsh when librmt is used, but typically it will be alive until
> the end of the backup and in any case will be cleaned up when
> xfsdump/restore exits.
> Signed-off-by: Bill Kendall <wkendall@xxxxxxx>

Looks OK to me.

Reviewed-by: Dave Chinner <dchinner@xxxxxxxxxx>
Dave Chinner

<Prev in Thread] Current Thread [Next in Thread>