search for: fuse_loop

...chard! Maybe the function guestfs_mount_local_run shouldn't ACQUIRE_LOCK_FOR_CURRENT_SCOPE as it doesn't talk with the daemon and sits in the loop? What do you think? If I remove it from guestfs_mount_local_run (in lib/action-1.c, don't know how to properly remove it from ml generator), fuse_loop_mt works, but I still don't understand how it worked with fuse_loop (single threaded) when guestfs_mount_local_run did ACQUIRE_LOCK_FOR_CURRENT_SCOPE. Unfortunately multiple ls -lR to the same directory tree lead to crash while it seems multiple ls -lR to different directory trees (if not repea...

On Mon, Jun 26, 2017 at 10:27:54AM +0300, Maxim Kozover wrote: > I'd like to ask you, please, 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

...12 @@ guestfs__mount_local_run (guestfs_h *g) return -1; } + /* Test if root is mounted. We do this by using a side-effect of + * guestfs_exists (which is that it calls NEED_ROOT). + */ + if (guestfs_exists (g, "/") == -1) + return -1; + debug (g, "%s: entering fuse_loop", __func__); /* Enter the main loop. */ -- 1.8.4.2

...ly I achieved a negative result, maybe you could help, please? . > I'm using libguestfs-1.36.4 as a base since I changed for myself a bit some > detection stuff that you recently moved from C to OCaml and I can't rewrite > it immediately. > > WIth vanilla 1.36.4 just changing fuse_loop to fuse_loop_mt gives almost > immediate crash when the filesystem is accessed. That's expected because plain 1.36 doesn't support multithreading, but ... > I've put the most recent gnulib, changed a bit bootstrap etc, put the > patches from https://www.redhat.com/archives/li...

...e that specific lock as the > function won't exit until umount and will sit in the loop. I think it does > nothing libguestfs-related, only fuse loop activation. > What I don't understand is how that lock in guestfs_mount_local_run didn't > make problems with single threaded fuse_loop. > I'll try to run it a bit more to see if any problems are seen. > If everything is OK (hope not a false success as directory lists are > slower and race condition maybe less likely), then it should be worth to > see why directory cache made problems, maybe guard it with the same l...

...the debug dump information, ?? version = 1.17.40.Root device: /dev/vda1 (this is test output) libguestfs: guestfs__mount_local: fuse_mount /mnt/libg libguestfs: guestfs__mount_local: fuse_new libguestfs: guestfs__mount_local: leaving fuse_mount_local libguestfs: guestfs__mount_local_run: entering fuse_loop libguestfs: send_to_daemon: 56 bytes: 00 00 00 34 | 20 00 f5 f5 | 00 00 00 04 | 00 00 00 35 | 00 00 00 00 | ... guestfsd: main_loop: proc 11 (lvs) took 0.04 seconds guestfsd: main_loop: new request, len 0x34 guestfsd: error: lstat_stub: you must call 'mount' first to mount the root filesy...

On Mon, Oct 16, 2017 at 10:16:27PM +0300, Maxim Kozover wrote: > I mean if after applying multithreading patches I can change fuse_loop to > fuse_loop_mt... OK, I've not actually tested how well that works myself, so make sure you test it properly before doing anything important with it. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: htt...

...th the daemon and sits > in the loop? What do you think? The lock is needed for any access to the guestfs_h structure, so I'm pretty sure that is not safe. > If I remove it from guestfs_mount_local_run (in lib/action-1.c, don't know > how to properly remove it from ml generator), fuse_loop_mt works, but I > still don't understand how it worked with fuse_loop (single threaded) when > guestfs_mount_local_run did ACQUIRE_LOCK_FOR_CURRENT_SCOPE. > Unfortunately multiple ls -lR to the same directory tree lead to crash > while it seems multiple ls -lR to different directory...

...; return -1; > } > > + /* Test if root is mounted. We do this by using a side-effect of > + * guestfs_exists (which is that it calls NEED_ROOT). > + */ > + if (guestfs_exists (g, "/") == -1) > + return -1; > + > debug (g, "%s: entering fuse_loop", __func__); > > /* Enter the main loop. */ Sounds good (you are fast :) ) The only drawback is that the guestfish command above will leave the local FUSE mountpoint still mounted after the guestfish run. Not sure whether it is worth doing anything automatic about that though, may...

...+ > + /* Ready to serve, write pidfile. */ > + if (pidfile) { > + fp = fopen (pidfile, "w"); > + if (fp) { > + fprintf (fp, "%ld", (long) getpid ()); > + fclose (fp); > + } > + } > + > + /* Enter the main loop. */ > + r = fuse_loop (fuse); > + if (r != 0) > + perror ("fuse_loop"); > + > + /* Close FUSE. */ > + fuse_unmount (mountpoint, ch); > + fuse_destroy (fuse); > + > + /* Close NBD handle. */ > + nbd_close (nbd); > + > + free (mountpoint); > + free (filename); >...

...&sa, NULL); + sigaction (SIGQUIT, &sa, NULL); + + /* Ready to serve, write pidfile. */ + if (pidfile) { + fp = fopen (pidfile, "w"); + if (fp) { + fprintf (fp, "%ld", (long) getpid ()); + fclose (fp); + } + } + + /* Enter the main loop. */ + r = fuse_loop (fuse); + if (r != 0) + perror ("fuse_loop"); + + /* Close FUSE. */ + fuse_unmount (mountpoint, ch); + fuse_destroy (fuse); + + /* Close NBD handle. */ + nbd_close (nbd); + + free (mountpoint); + free (filename); + free (fuse_options); + + exit (r == 0 ? EXIT_SUCCESS : EXIT_F...

This version doesn't crash or cause hung processes or stuck mountpoints, so that's an improvement. Rich.

This patch is just for review. It enables FUSE support in the API via two new calls, 'guestfs_mount_local' and 'guestfs_umount_local'. FUSE turns out to be very easy to deadlock (necessitating that the machine be rebooted). Running the test from the third patch is usually an effective way to demonstrate this. However I have not yet managed to produce a simple reproducer that

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

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.