Libguestfs - Feb 2014 - Re: progress output during guestfish sh commands

Is there any way to flush the output of a long running 'guestfish sh
cmd.sh' call?
It seems to me that output is only shown once cmd.sh has finished. I
already split cmd.sh into smaller pieces to see overall progress. But
output from a verbose, long running single command within cmd.sh is not
shown.

Olaf

On Tue, Feb 04, 2014 at 10:43:28AM +0100, Olaf Hering
wrote:
> Is there any way to flush the output of a long running 'guestfish sh
> cmd.sh' call?
No.  At the protocol level, the output is only sent in the reply
message, which also completes the RPC call:

http://libguestfs.org/guestfs.3.html#communication-protocol
> It seems to me that output is only shown once cmd.sh has finished. I
> already split cmd.sh into smaller pieces to see overall progress. But
> output from a verbose, long running single command within cmd.sh is not
> shown.
Verbose output is carried over a separate channel from qemu, so things
like kernel messages appear asynchronously:

https://github.com/libguestfs/libguestfs/blob/master/src/conn-socket.c#L301

However the command output (both stdout & stderr) is captured into a
string buffer in the daemon, so it does not appear in verbose output:

https://github.com/libguestfs/libguestfs/blob/master/daemon/command.c#L270

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org

On Tue, Feb 04, Richard W.M. Jones wrote:
> > It seems to me that output is only shown once cmd.sh has finished. I
> > already split cmd.sh into smaller pieces to see overall progress. But
> > output from a verbose, long running single command within cmd.sh is
not
> > shown.
> 
> Verbose output is carried over a separate channel from qemu, so things
> like kernel messages appear asynchronously:
> 
> https://github.com/libguestfs/libguestfs/blob/master/src/conn-socket.c#L301
Thanks.
I think doing 'cmd < /dev/null &> /dev/kmsg' will help, I will
try that
way to see whats actually going on.

Olaf