search for: stdin_fd

...* This is so we can ignore this device from the point of view of the * user, eg. in guestfs_list_devices and many other places. @@ -834,22 +838,22 @@ commandrvf (char **stdoutput, char **stderror, int flags, signal (SIGPIPE, SIG_DFL); close (0); if (flag_copy_stdin) { - dup2 (stdin_fd[0], 0); - close (stdin_fd[0]); - close (stdin_fd[1]); + dup2 (stdin_fd[PIPE_READ], STDIN_FILENO); + close (stdin_fd[PIPE_READ]); + close (stdin_fd[PIPE_WRITE]); } else { /* Set stdin to /dev/null (ignore failure) */ ignore_value (open ("/dev/null&quo...

...ot;/bin/pwd" (unreachable)/ ><fs> sh "cd / ; /bin/pwd" / This untested change may fix it. =================== --- libguestfs-1.20.10.orig/daemon/guestfsd.c +++ libguestfs-1.20.10/daemon/guestfsd.c @@ -879,7 +879,11 @@ commandrvf (char **stdoutput, char **std close (stdin_fd[PIPE_READ]); close (stdin_fd[PIPE_WRITE]); - if (chroot (sysroot) == -1) { + if (chdir (sysroot) == -1) { + perror ("chdir"); + _exit (EXIT_FAILURE); + } + if (chroot (".") == -1) { perror ("chroot"); _exit (...

...gt; sh "cd / ; /bin/pwd" > / > > This untested change may fix it. > > =================== > --- libguestfs-1.20.10.orig/daemon/guestfsd.c > +++ libguestfs-1.20.10/daemon/guestfsd.c > @@ -879,7 +879,11 @@ commandrvf (char **stdoutput, char **std > close (stdin_fd[PIPE_READ]); > close (stdin_fd[PIPE_WRITE]); > > - if (chroot (sysroot) == -1) { > + if (chdir (sysroot) == -1) { > + perror ("chdir"); > + _exit (EXIT_FAILURE); > + } > + if (chroot (".") == -1) { >...

...t_chan = Filename.open_temp_file "cmd" ".out" in > + let stderr_file, stderr_chan = Filename.open_temp_file "cmd" ".err" in > + let stdout_fd = descr_of_out_channel stdout_chan in > + let stderr_fd = descr_of_out_channel stderr_chan in > + let stdin_fd = openfile "/dev/null" [O_RDONLY] 0 in > + > + let pid = fork () in > + if pid = 0 then ( > + (* Child process. *) > + dup2 stdin_fd stdin; > + close stdin_fd; > + dup2 stdout_fd stdout; > + close stdout_fd; > + dup2 stderr_fd stderr; > +...

Commits 3c27f3d91e1566854747bbe844186783fc84f3a8 and 1b6f0daa9ae7fcc94e389232d0c397816cda973d added an internal API for running commands asynchronously. It is only used by the copy-in and copy-out APIs. Unfortunately this made the command code very complex: it was almost impossible to redirect stderr to a file, and there were a lot of long-range dependencies through the file. It was also buggy:

Hi, attached there is the second version of the patch series adding copy_in and copy_out in the library, mostly moving them from guestfish. It also adds the copy_in usage in virt-customize, as aid in a new image building. Thanks, Pino Toscano (7): cmd: add a way to run (and wait) asynchronously commands cmd: add a child-setup callback cmd: add the possibility to get a fd to the process

--- src/command.c | 64 +++++++++++++++++++++++++++++++++++++++++++------- src/guestfs-internal.h | 3 +++ 2 files changed, 58 insertions(+), 9 deletions(-) diff --git a/src/command.c b/src/command.c index 4bb469b..e26573d 100644 --- a/src/command.c +++ b/src/command.c @@ -360,7 +360,7 @@ debug_command (struct command *cmd) } static int -run_command (struct command *cmd)

...t stdout_file, stdout_chan = Filename.open_temp_file "cmd" ".out" in + let stderr_file, stderr_chan = Filename.open_temp_file "cmd" ".err" in + let stdout_fd = descr_of_out_channel stdout_chan in + let stderr_fd = descr_of_out_channel stderr_chan in + let stdin_fd = openfile "/dev/null" [O_RDONLY] 0 in + + let pid = fork () in + if pid = 0 then ( + (* Child process. *) + dup2 stdin_fd stdin; + close stdin_fd; + dup2 stdout_fd stdout; + close stdout_fd; + dup2 stderr_fd stderr; + close stderr_fd; + + execvp prog argv + );...

All, These days I am trying to understand the interaction relationship between the libvirt and KVM kernel module, eg. kvm_intel.ko. We know that KVM kernel module expose an entry in form of device file "/dev/kvm" which can be accessed by user space application to control, for example, create a VM using KVM_CREATE_VM with help of ioctl. Now let's say the tool virsh based upon

This patch series is just FYI at the moment. However it does pass the tests. The daemon is a self-contained program. We don't need to write it all in C. Writing parts of it in OCaml would make it simpler and less error-prone. In particular if the daemon was written in a more sane programming language then we could move the inspection code to run entirely inside the appliance, which would

...t stdout_file, stdout_chan = Filename.open_temp_file "cmd" ".out" in + let stderr_file, stderr_chan = Filename.open_temp_file "cmd" ".err" in + let stdout_fd = descr_of_out_channel stdout_chan in + let stderr_fd = descr_of_out_channel stderr_chan in + let stdin_fd = openfile "/dev/null" [O_RDONLY] 0 in + + let pid = fork () in + if pid = 0 then ( + (* Child process. *) + dup2 stdin_fd stdin; + close stdin_fd; + if not fold_stdout_on_stderr then + dup2 stdout_fd stdout + else + dup2 stderr_fd stdout; + close stdout_fd;...

I ran the Coverity static analyzer[1] on libguestfs, and fixed many errors as a result. Coverity found some errors in gnulib, but it doesn't seem to be worth following those up since the version of gnulib we are using is so old. There are a couple more errors (possibly 1 false-positive) which I'm going to send in a separate email. BTW all the errors found by Coverity were in the daemon

Previously posted as part of the mega utilities/inspection series here: https://www.redhat.com/archives/libguestfs/2017-June/msg00232.html What I've done is to extract just the parts related to rewriting daemon APIs in OCaml, rebase them on top of the current master, fix a few things, and recompile and test everything. Rich.

Version 1 was here: https://www.redhat.com/archives/libguestfs/2017-June/msg00003.html This patch series reimplements a few more APIs in OCaml, including some very important core APIs like ?list_filesystems? and ?mount?. All the tests pass after this. The selection of APIs that I have moved may look a little random, but in fact they are all APIs consumed by the inspection code (and some more

v2 was here: https://www.redhat.com/archives/libguestfs/2017-June/msg00008.html This series gets as far as a working (and faster) reimplementation of ‘guestfs_list_filesystems’. I also have another patch series on top of this one which reimplements the inspection APIs inside the daemon, but that needs a bit more work still, since inspection turns out to be a very large piece of code. Rich.

I think this fixes everything mentioned: - Added the Optgroups module as suggested. - Remove command temporary files. - Replace command ~flags with ?fold_stdout_on_stderr. - Nest _with_mounted function. - Rebase & retest. Rich.

v1 was posted here: https://www.redhat.com/archives/libguestfs/2017-July/msg00098.html This series now depends on two small patches which I posted separately: https://www.redhat.com/archives/libguestfs/2017-July/msg00207.html https://www.redhat.com/archives/libguestfs/2017-July/msg00209.html v1 -> v2: - Previously changes to generator/daemon.ml were made incrementally through the patch

These two patches are probably not completely independent, but separating them is a lot of work. With *both* patches applied, all the tests and extra-tests pass. That's no guarantee however that there isn't a mistake, so I don't think this patch is a candidate for the 1.16 branch, until it's had a lot more testing in development. Rich.

v6 was posted here: https://www.redhat.com/archives/libguestfs/2017-June/msg00103.html and this requires the utilities refactoring posted here: https://www.redhat.com/archives/libguestfs/2017-June/msg00169.html Inspection is now complete[*], although not very well tested. I'm intending to compare the output of many guests using old & new virt-inspector to see if I can find any

libguestfs has used double and triple underscores in identifiers. These aren't valid for global names in C++. (http://stackoverflow.com/a/228797) These large but completely mechanical patches change the illegal identifiers to legal ones. Rich.