search for: autosync_umount

...--git a/daemon/internal.c b/daemon/internal.c index 781366d..5fb3d54 100644 --- a/daemon/internal.c +++ b/daemon/internal.c @@ -46,14 +46,9 @@ do_internal_autosync (void) } /* NB: Only called when valgrinding the daemon. */ -int +int __attribute__((noreturn)) do_internal_exit (void) { - if (!autosync_umount) { - reply_with_error ("guestfsd -r flag used, ignoring"); - return -1; - } - /* Send a reply before exiting so the protocol doesn't get confused. */ reply (NULL, NULL); diff --git a/generator/actions.ml b/generator/actions.ml index 24e84b5..a48d8ce 100644 --- a/generat...

...lib; recent versions are able to get the name of the current program on their own. --- daemon/guestfsd.c | 3 --- 1 file changed, 3 deletions(-) diff --git a/daemon/guestfsd.c b/daemon/guestfsd.c index b129ad0..85ce5d2 100644 --- a/daemon/guestfsd.c +++ b/daemon/guestfsd.c @@ -125,9 +125,6 @@ int autosync_umount = 1; /* If set, we are testing the daemon as part of the libguestfs tests. */ int test_mode = 0; -/* Not used explicitly, but required by the gnulib 'error' module. */ -const char *program_name = "guestfsd"; - /* Name of the virtio-serial channel. */ #define VIRTIO_SERIAL_CH...

In v2: - Kernel command line parsing now moved to the appliance. - In the captive daemon test, the daemon cleanly shuts down on exit. - Add another btrfs test. Rich.

Currently we are unable to properly run guestfsd (the daemon) under valgrind. Attempts to run valgrind inside the appliance have not been successful (see patch 1/7). However we desperately need better valgrind coverage of the daemon, particularly because it is doing a lot of complex parsing of program output. This has been a problem for a long time. A better way to attack this problem is to

Hi, this series update libguestfs to a recent gnulib version, so that we can use its new getprogname module, and solve altogether one of the porting issues (the need for 'program_name' by the error module of gnulib), and have a single way to get the name of the current program. A number of changes in tools mostly, although mechanical. Thanks, Pino Toscano (3): Update gnulib to latest

https://bugzilla.redhat.com/show_bug.cgi?id=1477623 The first two patches are cleanups. The third patch changes the way that we handle Device and Dev_or_Path parameters so that a parameter marked as such can really only contain a block device name (and not, for instance, a chardev). Using a chardev here caused hangs in the API. The next two patches fix API usage to conform to this new stricter

Replace GUESTFSD_EXT_CMD with a command line option ‘./guestfsd --print-external-commands’