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

[Tommy Wu-3]

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
[hidden email]
http://oss.sgi.com/mailman/listinfo/xfs

[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
[hidden email]
http://oss.sgi.com/mailman/listinfo/xfs

[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 <[hidden email]>
---
 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
[hidden email]
http://oss.sgi.com/mailman/listinfo/xfs

[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 <[hidden email]>

Looks OK to me.

Reviewed-by: Dave Chinner <[hidden email]>
--
Dave Chinner
[hidden email]

_______________________________________________
xfs mailing list
[hidden email]
http://oss.sgi.com/mailman/listinfo/xfs