From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: [PATCH] fix migration failure with xl migrate --debug Date: Wed, 26 Nov 2014 21:17:56 +0000 Message-ID: <54764384.5010008@citrix.com> References: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3959838990604110159==" Return-path: In-Reply-To: List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: M A Young , xen-devel@lists.xen.org Cc: Ian Jackson , Wei Liu , Ian Campbell , Stefano Stabellini List-Id: xen-devel@lists.xenproject.org This is a multi-part message in MIME format. --===============3959838990604110159== Content-Type: multipart/alternative; boundary="------------090107030203060309010900" This is a multi-part message in MIME format. --------------090107030203060309010900 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On 26/11/2014 20:51, M A Young wrote: > Migrations with xl migrate --debug will fail because debugging > information from the receiving process is written to the stdout > channel. This channel is also used for status messages so the > migration will fail as the sending process receives an unexpected > message. This patch moves the debugging information to the stderr > channel. > > Signed-off-by: Michael Young Ah yes - that will do. The whole info/error/debug handling here is a mess. Amongst other issues, it is not possible to distinguish whether libxc logging messages are coming from the sending or receiving side, without judging the context from the text itself. > > Use stderr for debugging messages for xl migrate --debug as stdout is used > for status messages. > > --- xen-4.5.0-rc1/tools/libxl/xl_cmdimpl.c.orig 2014-10-24 15:22:40.000000000 +0100 > +++ xen-4.5.0-rc1/tools/libxl/xl_cmdimpl.c 2014-11-25 20:29:06.723856433 +0000 > @@ -383,7 +383,7 @@ Sadly, changing printf_info() like this has an unintended knock-on effect to create_domain() (xl create, migrate-recevive, restore) and xl config-update. I think you might have to pass FILE pointers all the way through. > libxl_domain_config *d_config) > { > if (output_format == OUTPUT_FORMAT_SXP) > - return printf_info_sexp(domid, d_config); > + return printf_info_sexp(domid, d_config, stderr); > > const char *buf; > libxl_yajl_length len = 0; > @@ -404,7 +404,7 @@ > if (s != yajl_gen_status_ok) > goto out; > > - puts(buf); > + fputs(buf,stderr); puts() and fputs() are not quite synonymous. puts() will unconditionally add an extra newline to stdout. It is unclear whether the string from yajl_gen_get_buf() comes with a trailing newline or not. If the output looks ok, it probably is fine. ~Andrew --------------090107030203060309010900 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 26/11/2014 20:51, M A Young wrote:
Migrations with xl migrate --debug will fail because debugging information from the receiving process is written to the stdout channel. This channel is also used for status messages so the migration will fail as the sending process receives an unexpected message. This patch moves the debugging information to the stderr channel.

Signed-off-by: Michael Young <m.a.young@durham.ac.uk>

Ah yes - that will do.

The whole info/error/debug handling here is a mess.  Amongst other issues, it is not possible to distinguish whether libxc logging messages are coming from the sending or receiving side, without judging the context from the text itself.


Use stderr for debugging messages for xl migrate --debug as stdout is used
for status messages.

--- xen-4.5.0-rc1/tools/libxl/xl_cmdimpl.c.orig	2014-10-24 15:22:40.000000000 +0100
+++ xen-4.5.0-rc1/tools/libxl/xl_cmdimpl.c	2014-11-25 20:29:06.723856433 +0000
@@ -383,7 +383,7 @@

Sadly, changing printf_info() like this has an unintended knock-on effect to create_domain() (xl create, migrate-recevive, restore) and xl config-update.  I think you might have to pass FILE pointers all the way through.

                         libxl_domain_config *d_config)
 {
     if (output_format == OUTPUT_FORMAT_SXP)
-        return printf_info_sexp(domid, d_config);
+        return printf_info_sexp(domid, d_config, stderr);
 
     const char *buf;
     libxl_yajl_length len = 0;
@@ -404,7 +404,7 @@
     if (s != yajl_gen_status_ok)
         goto out;
 
-    puts(buf);
+    fputs(buf,stderr);

puts() and fputs() are not quite synonymous.  puts() will unconditionally add an extra newline to stdout.  It is unclear whether the string from yajl_gen_get_buf() comes with a trailing newline or not.  If the output looks ok, it probably is fine.

~Andrew
--------------090107030203060309010900-- --===============3959838990604110159== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Xen-devel mailing list Xen-devel@lists.xen.org http://lists.xen.org/xen-devel --===============3959838990604110159==--