search for: mount_local_run

...e to call guestunmount. There's a dim place: what is the difference between guestunmount and guestfs_umount_local? As I understood, guestunmount does need guestfs handle, launch etc. Does umount_local need it? If yes, how should this command be used (assumed that the handle is already used in mount_local_run)? These questions confuse me a little :-s -- Your sincerely, Maxim Perevedentsev

"localmountpoint" parameter is allocated in JNI before calling mount_local and freed afterward. But guestfs handle keeps reference to passed "localmountpoint" parameter and will try to access it in umount_local and free after mount_local_run caller thread ends which leads to a crash (an attempt to access to already freed memory). --- lib/fuse.c | 5 +++-- lib/handle.c | 1 + 2 files changed, 4 insertions(+), 2 deletions(-) diff --git a/lib/fuse.c b/lib/fuse.c index 9731db962..82bddec00 100644 --- a/lib/fuse.c +++ b/lib/fuse.c @@ -1...

Hello everyone! I have to implement the functionality of mounting all VM disks/partitions. E.g. if a VM has 2 disks of 2 partitions each (I get it from virt-filesystems), I want to get the following structure on host node after mount: mnt/ ------hdd0/ -------------volume1/ -------------volume2/ ------hdd1/ -------------volume1/ -------------volume2/ I'd like to use guestmount due to

...ease, about multithreading with libguestfs. > I'm using libguestfs 1.36.4 with Perl front-end. > > Should it be possible to have the same libguestfs appliance provide both > fuse interface and periodically perform some longer APIs like find0? > > I mean make one Perl thread do mount_local_run and another thread > periodically run find0 that executes simultaneously with fuse (hopefully > not blocking fuse functionality internally until find0 exits)? Unfortunately not, and as you discovered it will (currently) crash. > When I'm trying this, the whole thing crashes, so the q...

...; 0 then retcode + else loop xs + | [] -> 0 + in + let retcode = loop scripts in + if debug >= 1 then ( + print_string (timing_output ~target_name:hook_name scripts timings) + ); + retcode + in + + g#mount_local mount_dir; + let pid = fork_and_run () in + g#mount_local_run (); + + (match snd (Unix.waitpid [] pid) with + | Unix.WEXITED 0 -> () + | Unix.WEXITED i -> exit i + | Unix.WSIGNALED i + | Unix.WSTOPPED i -> + error (f_"sub-process killed by signal (%d)") i ); + flush_all () let run_install_packages ~debug ~blockdev ~log_file...

Move the OCaml binding to C _exit to an own module. Just code motion, adapting v2v in the process. --- docs/C_SOURCE_FILES | 2 +- mllib/Makefile.am | 5 ++++- mllib/exit-c.c | 33 +++++++++++++++++++++++++++++++++ mllib/exit.ml | 19 +++++++++++++++++++ mllib/exit.mli | 20 ++++++++++++++++++++ v2v/Makefile.am | 1 - v2v/changeuid-c.c | 33

This changes the proposed API slightly. Previously 'mount-local' generating a 'mounted' event when the filesystem was ready, and from the 'mounted' event you had to effectively do a fork. Now, 'mount-local' just initializes the mountpoint and you have to call 'mount-local-run' to enter the FUSE main loop. Between these calls you can do a fork or whatever

The existing mechanism was clunky, slow and used ~ 10 MB of local disk. Rich.

Split up the huge generator/actions.ml into several smaller files. Rich.