similar to: [PATCH] launch: Close file descriptors after fork (RHBZ#1123007).

Hi Richard, I see this patch is included into libguestfs >= 1.26.6 & libguestfs >= 1.27.24. I feel that version is too high. Now RHEL 7.0 runs libguestfs-1.22.6, RHEL 6.6 alpha and 6.5 runs libguestfs-1.20.11. Is that possible to backport this patch, in order to make this problem fixed in RHEL 7.0, 6.6, and 6.5? Thanks & Best Regards Qin Zhao (赵钦) China System and Technology Lab,

https://bugzilla.redhat.com/show_bug.cgi?id=1123007 This is version 2 of the patch which avoids incorrectly closing stderr, so we can still see debug and error messages. Rich.

If SIGTERM is blocked in the main program, then it ends up still being blocked in the subprocess after we fork. This means that we cannot kill qemu by sending SIGTERM to it. This commit fixes the problem by unblocking SIGTERM unconditionally after fork. Thanks: wtfuzz on IRC for reporting and analysis. --- lib/launch-direct.c | 15 +++++++++++++++ lib/launch-uml.c | 11 +++++++++++ 2 files

v1 was here: https://www.redhat.com/archives/libguestfs/2013-August/msg00005.html This now works, to some extent. The main problem now is that devices are named /dev/ubd[a-] which of course confuses everything. I'm thinking it may be easier to add a udev rule to rename them. Rich.

This is a User-Mode Linux backend for libguestfs. You can select it by doing: export LIBGUESTFS_BACKEND=uml export LIBGUESTFS_QEMU=/path/to/vmlinux Note we're reusing the 'qemu' variable in the handle for convenience. QEmu is not involved when using the UML backend. This almost works. UML itself crashes when the daemon tries to connect to the serial port. I suspect it's

From: "Richard W.M. Jones" <rjones at redhat.com> If the parent process uses a pipe (or any fd, but pipes are a particular problem), then the recovery process would hold open the file descriptor(s) of the pipe, meaning that it could not be fully closed in the parent. Because the recovery process doesn't use exec(2), this wasn't avoidable even using FD_CLOEXEC. Avoid this

Add some warnings. Well, the first patch is a miscellaneous change, but patches 2-5 add some warnings. Rich.

The last (only?) caller of guestfs_int_cmd_clear_close_files() disappeared in commit e4c396888056 ("lib/info: Remove /dev/fd hacking and pass a true filename to qemu-img info.", 2018-01-23), part of v1.37.36. Simplify the code by removing guestfs_int_cmd_clear_close_files(). Signed-off-by: Laszlo Ersek <lersek at redhat.com> --- lib/guestfs-internal.h | 1 - lib/command.c

This function was kind of like debug(), except that it didn't check the g->verbose flag and it only worked in the library (it would crash if used after fork). It also wasn't very useful. The sort of boot analysis done by tests/qemu/boot-analysis.c means that timestamping (some) messages is even less interesting than before. Remove it and replace calls with debug() instead. ---

Thanks: Eric Blake. --- src/Makefile.am | 1 + src/command.c | 7 ++---- src/guestfs-internal.h | 4 +++ src/launch-direct.c | 11 +++------ src/launch-uml.c | 11 +++------ src/umask.c | 10 ++------ src/wait.c | 67 ++++++++++++++++++++++++++++++++++++++++++++++++++ 7 files changed, 84 insertions(+), 27 deletions(-) create mode 100644

comments? alternatives: sigsetjmp(ugly) and pselect(not portable, available) drawback: additional filedescriptors. Index: serverloop.c =================================================================== RCS file: /home/markus/cvs/ssh/serverloop.c,v retrieving revision 1.82 diff -u -r1.82 serverloop.c --- serverloop.c 10 Oct 2001 22:18:47 -0000 1.82 +++ serverloop.c 11 Oct 2001 18:06:33 -0000 @@

As Eric Blake noted in: https://www.redhat.com/archives/libguestfs/2016-April/msg00154.html libguestfs doesn't correctly handle the case where waitpid receives a SIGCHLD signal and the main program has registered a non-restartable signal handler. In this case waitpid would return -EINTR and we would print an error, but actually we should retry this case. This adds two new internal functions,

We recently tried upgrading openssh from 2.5.2p2 to 2.9p1 and discovered that it no longer worked to feed the output from a remote command into a pipe, unless the output was short and the pipe was very fast at processing its input. Example 1: ssh remote_machine some_command | less (where "some_command" generates a lot of output) now fails after the first screenful, with a

Instead of forcing valgrind to be run when --enable-valgrind-daemon is passed to configure, enable it only when the backend setting "valgrind_daemon" is set. This allows developers to keep building with --enable-valgrind-daemon, which unconditionally adds valgrind in the appliance but using only when requested. When --enable-valgrind-daemon is not passed (typical for release builds),

The drive used for the appliance is a raw (sparse) disk: specify that explicitly in its -drive qemu command line options, so qemu can skip the autodetection of its format and save a tiny bit of time. --- src/launch-direct.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/src/launch-direct.c b/src/launch-direct.c index ee0a855..8521e5a 100644 --- a/src/launch-direct.c +++

Error out early if the path to the socket will not fit into sockaddr_un::sun_path, as we will not be able to connect to it. --- src/launch-unix.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/src/launch-unix.c b/src/launch-unix.c index 740c554..973e14b 100644 --- a/src/launch-unix.c +++ b/src/launch-unix.c @@ -47,6 +47,12 @@ launch_unix (guestfs_h *g, void *datav, const char

This is the libguestfs companion patch to: https://www.redhat.com/archives/libguestfs/2013-September/msg00045.html Rich.

The original implementation utilies select(). In Linux select() typically supports up to 1024 file descriptors. This can be a problem when user tries to boot up many guests. Switching to poll() has minimum impact on existing code and has better scalibility. Up to 8192 file descriptors are supported in the current implementation. Signed-off-by: Wei Liu <wei.liu2@citrix.com> ---

This QEMU property is specific to x86/x86_64, so add it only on these architectures. --- lib/launch-direct.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/lib/launch-direct.c b/lib/launch-direct.c index bc43dcea2..3b848165c 100644 --- a/lib/launch-direct.c +++ b/lib/launch-direct.c @@ -519,8 +519,10 @@ launch_direct (guestfs_h *g, void *datav, const char *arg) arg ("-rtc",

virtio-scsi has been supported in qemu since 2012, and it is superior in every respect to virtio-blk. There's no reason to still be using virtio-blk. virtio-scsi support was initially added in 2012 (commit 0c0a7d0d868d153adf0600189f771459e1068b0a). You can still use virtio-blk using the (deprecated) iface parameter, but don't do that in new code. --- lib/guestfs-internal.h | 1 -