search for: guestfs_int_cmd_pipe_run

...was about to run when debugging was enabled. Fixes commit e98bb8692929a037f3452686719504aea31f311d. --- lib/command.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/lib/command.c b/lib/command.c index 970acf6e5..bc469de59 100644 --- a/lib/command.c +++ b/lib/command.c @@ -791,6 +791,9 @@ guestfs_int_cmd_pipe_run (struct command *cmd, const char *mode) finish_command (cmd); + if (cmd->g->verbose) + debug_command (cmd); + /* Various options cannot be used here. */ assert (!cmd->capture_errors); assert (!cmd->stdout_callback); -- 2.13.2

On Tuesday, 19 September 2017 13:38:27 CEST Richard W.M. Jones wrote: > diff --git a/lib/command.c b/lib/command.c > index bc469de59..7018c3ac0 100644 > --- a/lib/command.c > +++ b/lib/command.c > @@ -815,8 +815,9 @@ guestfs_int_cmd_pipe_run (struct command *cmd, const char *mode) > if (guestfs_int_lazy_make_tmpdir (cmd->g) == -1) > goto error; > > - cmd->error_file = > - safe_asprintf (cmd->g, "%s/cmderr.%d", cmd->g->tmpdir, ++cmd->g->unique); > + cmd->error_file = gue...

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:

...-1; guestfs_int_cmd_add_arg (copycmd, "cp"); guestfs_int_cmd_add_arg (copycmd, varsfile); guestfs_int_cmd_add_arg (copycmd, varst); diff --git a/lib/command.c b/lib/command.c index bc469de59..7018c3ac0 100644 --- a/lib/command.c +++ b/lib/command.c @@ -815,8 +815,9 @@ guestfs_int_cmd_pipe_run (struct command *cmd, const char *mode) if (guestfs_int_lazy_make_tmpdir (cmd->g) == -1) goto error; - cmd->error_file = - safe_asprintf (cmd->g, "%s/cmderr.%d", cmd->g->tmpdir, ++cmd->g->unique); + cmd->error_file = guestfs_int_make_temp_path (cmd-&...

...uoted (cmd, +#ifdef MACHINE_TYPE + MACHINE_TYPE "," +#endif + "accel=kvm:tcg"); + guestfs_int_cmd_add_string_unquoted (cmd, " -qmp stdio"); + guestfs_int_cmd_clear_capture_errors (cmd); + + fd = guestfs_int_cmd_pipe_run (cmd, "r"); + if (fd == -1) + return -1; + + /* Read the output line by line. We expect to see: + * line 1: {"QMP": {"version": ... } } # greeting from QMP + * line 2: {"return": {}} # output from qmp_capabilities + * line 3: {&qu...

Miscellaneous small cleanups in lib/ directory. Rich.

v1 -> v2: - Remove the unnecessary calls to guestfs_int_lazy_make_tmpdir in the final patch. Rich.

The patch I posted last week to disable mandatory locking for readonly drives (https://www.redhat.com/archives/libguestfs/2017-September/msg00013.html) was wrong in a couple of respects. Firstly it didn't work, which I didn't detect because my tests were testing the wrong thing. Oops. Secondly it used a simple version number check to detect qemu binaries implementing mandatory locking.

v2 -> v3: - I addressed everything that Pino mentioned last time. - It's tricky to get a stable run when multiple copies of qemu are involved, because the same cache files get overwritten by parallel libguestfs. So I changed the names of the cache files to include the qemu binary key (size, mtime), which removes this conflict. This is in new patch 4/6. Rich.

Patches 1-4 are almost the same as they are when previously posted here: https://www.redhat.com/archives/libguestfs/2017-September/msg00039.html Patch 5 actually uses the mandatory locking test to turn off locking in the narrow case where a drive is opened readonly, and then only for the drive being inspected. Passes ordinary tests (‘check-direct’ and ‘check-valgrind-direct’). Rich.