Bug 973138

Summary:	RFE: sh & debug sh should be able to capture all output and error return code
Product:	[Community] Virtualization Tools	Reporter:	Richard W.M. Jones <rjones>
Component:	libguestfs	Assignee:	Richard W.M. Jones <rjones>
Status:	NEW ---	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	unspecified	CC:	afazekas
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:		Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Richard W.M. Jones 2013-06-11 11:08:30 UTC

Description of problem:

12:00 < infernix> rwmjones: so one thing that i'm doing, for which i need that debug sh
12:00 < infernix> i'm running a custom tool and i need to capture its output and its return code
12:01 < infernix> it's a proprietary tool, statically compiled

Notice that because infernix is using a proprietary program,
adding it to the libguestfs API isn't really a good alternative.

"debug sh" -- or an additional command -- should be able to
capture all the output (even very large > 4 MB output) plus
the return code and return it all to the caller.

It's not clear if stdout and stderr should be captured separately.
This might be useful in some circumstances.

Version-Release number of selected component (if applicable):

libguestfs 1.22

Comment 1 Richard W.M. Jones 2013-07-09 08:40:03 UTC

This also happened for a user trying to do:

sh "rpm -Va"

Comment 2 Attila Fazekas 2019-03-19 18:52:07 UTC

The f28 version dies with oom on large output,
The f29 with libguestfs-1.40.1-2.fc29.x86_64 fails with:

realloc: Cannot allocate memory 

(OOM did not kicked in)

Steps to reproduce:

curl -Lo fedora.qcow2 https://download.fedoraproject.org/pub/fedora/linux/releases/29/Cloud/x86_64/images/Fedora-Cloud-Base-29-1.2.x86_64.qcow2
qemu-img create -b fedora.qcow2 -f qcow2 test.qcow2

time guestfish -a test.qcow2 -m /dev/sda1:/ sh 'cat /dev/sda1' 

libguestfs: error: sh: error running external command, see debug output for details

The error code is not preserved, but 0 or 1 is ok.
$ guestfish -a test.qcow2 -m /dev/sda1:/ sh 'exit 42' ; echo $?
1

Redirects does not seams to work:
$ guestfish -a test.qcow2 -m /dev/sda1:/ sh 'echo foo >&2'

(One line of nothing)

$ guestfish -a test.qcow2 -m /dev/sda1:/ sh 'ls /moo 2>&1'

(One line of nothing)

$ guestfish -a test.qcow2 -m /dev/sda1:/ sh 'echo muu' >/tmp/muu
$ hexdump -C /tmp/muu 
00000000  6d 75 75 0a 0a                                    |muu..|
00000005

Two new line instead of one.

$ guestfish -a test.qcow2 -m /dev/sda1:/ sh "echo $'\0'" >/tmp/muu
$ hexdump -C /tmp/muu 

00000000  0a                                                |.|
00000001

One new line instead of 0x00 .

I did not find a way to pass stdin however,
there are several copy in options.

Comment 3 Attila Fazekas 2019-03-20 09:26:53 UTC

The question, what would be better as default exit
status in case there is failure outside the user script.

The error codes above 125 is reserved for the shell,
however only 64 signal defined in Linux (SIGRTMAX).

Linux status field allows to have 8 bit user controller exit status,
but the internal exit status has more bits.

The shell just maps the higher bits into the the lower bits

Typically the user space programs using 1..125 for indicating
error, typically starting from 1. 


POSIX did not forbidden the creative usage
of the above 128 statuses in any another way,
the shell is mandated to use 128+N codes for terminating on signal.

FreeBSD defined more signal, but 255 is still not used there.

ssh using 255 in case of ssh failure.
So the ssh behavior is the one which should be simulated.