xfsdump 3.0.6, ERROR: xfs_quota failed with exit status: -1

xfsdump 3.0.6, ERROR: xfs_quota failed with exit status: -1

[Tommy Wu]

Hi!

when I use xfsdump 3.0.6, it always got ERROR for xfs_quota like this:

/sbin/xfsdump: using file dump (drive_simple) strategy
/sbin/xfsdump: version 3.0.6 (dump format 3.0) - Running single-threaded
/sbin/xfsdump: saving user quota information for: /var/www
/sbin/xfsdump: ERROR: xfs_quota failed with exit status: -1
/sbin/xfsdump: ERROR: failed to save user quota information, continuing
/sbin/xfsdump: level 0 dump of fw1.teatime.com.tw:/var/www
/sbin/xfsdump: dump date: Tue Jan 10 10:34:24 2012

downgrade to 3.0.5, same command (also same xfsprogs 3.1.7), no any error:

/sbin/xfsdump: using file dump (drive_simple) strategy
/sbin/xfsdump: version 3.0.5 (dump format 3.0) - Running single-threaded
/sbin/xfsdump: saving user quota information for: /var/www
/sbin/xfsdump: level 0 dump of fw1.teatime.com.tw:/var/www
/sbin/xfsdump: dump date: Tue Jan 10 10:30:36 2012

But even it got error for xfs_quota, the xfsdump_quotas file was
created successful, I check the command used in xfsdump, the same
xfs_quota command work fine without any error in shell script (I also
write a simple C program to use system() to execute it, also no error
for such command).

-- 

Tommy Wu

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

Re: xfsdump 3.0.6, ERROR: xfs_quota failed with exit status: -1

[Bill Kendall]

On 01/09/2012 08:42 PM, Tommy Wu wrote:
> Hi!
>
> when I use xfsdump 3.0.6, it always got ERROR for xfs_quota like this:
>
> /sbin/xfsdump: using file dump (drive_simple) strategy
> /sbin/xfsdump: version 3.0.6 (dump format 3.0) - Running single-threaded
> /sbin/xfsdump: saving user quota information for: /var/www
> /sbin/xfsdump: ERROR: xfs_quota failed with exit status: -1
> /sbin/xfsdump: ERROR: failed to save user quota information, continuing
> /sbin/xfsdump: level 0 dump of fw1.teatime.com.tw:/var/www
> /sbin/xfsdump: dump date: Tue Jan 10 10:34:24 2012
>
> downgrade to 3.0.5, same command (also same xfsprogs 3.1.7), no any error:
>
> /sbin/xfsdump: using file dump (drive_simple) strategy
> /sbin/xfsdump: version 3.0.5 (dump format 3.0) - Running single-threaded
> /sbin/xfsdump: saving user quota information for: /var/www
> /sbin/xfsdump: level 0 dump of fw1.teatime.com.tw:/var/www
> /sbin/xfsdump: dump date: Tue Jan 10 10:30:36 2012
>
> But even it got error for xfs_quota, the xfsdump_quotas file was
> created successful, I check the command used in xfsdump, the same
> xfs_quota command work fine without any error in shell script (I also
> write a simple C program to use system() to execute it, also no error
> for such command).
>

In 3.0.6 SIGCHLD is explicitly ignored so that librmt processes are
automatically cleaned up if they exit early. Evidently this prevents
system() from retrieving the exit status. I'll work up a patch to
fix this.

Thanks,
Bill

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

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

[Bill Kendall]

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@sgi.com>
---
 common/main.c |   11 +++++++----
 1 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/common/main.c b/common/main.c
index 5880723..c9a311b 100644
--- a/common/main.c
+++ b/common/main.c
@@ -507,6 +507,13 @@ main( int argc, char *argv[] )
 	 * want to exit when a signal is received. otherwise, hold signals so
 	 * they don't interfere with sys calls; they will be released at
 	 * pre-emption points and upon pausing in the main loop.
+	 *
+	 * note that since we're multi-threaded, handling SIGCHLD causes
+	 * problems with system()'s ability to obtain a child's exit status
+	 * (because the main thread may process SIGCHLD before the thread
+	 * running system() calls waitpid()). likewise explicitly ignoring
+	 * SIGCHLD also prevents system() from getting an exit status.
+	 * therefore we don't do anything with SIGCHLD.
 	 */
 
 	sigfillset(&sa.sa_mask);
@@ -514,13 +521,9 @@ main( int argc, char *argv[] )
 
 	/* always ignore SIGPIPE, instead handle EPIPE as part
 	 * of normal sys call error handling.
-	 *
-	 * explicitly ignore SIGCHLD so that if librmt rsh sessions
-	 * exit early they do not become zombies.
 	 */
 	sa.sa_handler = SIG_IGN;
 	sigaction( SIGPIPE, &sa, NULL );
-	sigaction( SIGCHLD, &sa, NULL );
 
 	if ( ! pipeline ) {
 		sigset_t blocked_set;
-- 
1.7.0.4

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

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

[Dave Chinner]

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@sgi.com>

Looks OK to me.

Reviewed-by: Dave Chinner <dchinner@redhat.com>
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs