Bug 916780 - feature request: guestmount --with-cleanup-pipefd
Summary: feature request: guestmount --with-cleanup-pipefd
Keywords:
Status: CLOSED UPSTREAM
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libguestfs
Version: unspecified
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Richard W.M. Jones
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-02-28 21:29 UTC by Colin Walters
Modified: 2014-05-22 21:41 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2013-03-05 13:54:36 UTC
Embargoed:


Attachments (Terms of Use)

Description Colin Walters 2013-02-28 21:29:13 UTC
My software uses guestmount, then performs a bunch of operations directly on the mounted FS, then drops into code recommended from the guestfs man page of

while true; do sleep 1; fusermount -u ; done
while true; do sleep 1; if ! kill -0 $(cat guestmount.pid); then break; fi; done

This is awful for a variety of reasons.

1) Polling makes me look dumb.
2) I need a special SIGINT handler to perform this cleanup too.

The thing is that guestmount is in a good position to manage the lifecycle of the mount point itself.

What I want is to have my program allocate a pipe(2), and pass the descriptor to the guestmount child, and tell it what the fd is like --with-cleanup-pipefd=42.  Then guestmount would monitor this fd for POLLHUP.  If it's closed, then guestmount would internally do the fusermount -u and wait till it completes, then finally exit itself.  Oh and in this model, guestmount would not daemonize.

This solves 1) because I can simply have my program close() the pipe, and await termination via waitpid() without polling.

It also solves 2) because if my program dies for any reason, the pipe will be closed, and guestmount will know it should exit.  (In this model, guestmount should probably handle SIGINT internally by treating it as if the cleanup pipe was closed too).

Comment 1 Richard W.M. Jones 2013-03-01 15:06:13 UTC
I think this is a nice idea.  What would make it a great idea
would be some way to use it in a shell script, so that guestmount
can automagically detect when the shell script exits (for any
reason) and manage the closing and unmounting of the mountpoint.

After spending quite a bit of time reading bash(1) I can't
see how a shell script would open a pipe to a bare file
descriptor, although surely the sort of thing that must be
possible somehow.

Comment 2 Richard W.M. Jones 2013-03-05 13:54:36 UTC
This commits adds the new 'guestunmount' program with '--fd=<FD>'
option which should do what you want:

https://github.com/libguestfs/libguestfs/commit/3e9e40aee322789e7f81422f4cfd42915b36eb4c

The feature will appear in libguestfs 1.21.17 / 1.22.

Comment 4 Colin Walters 2014-05-22 19:19:48 UTC
I'm not sure how to use --no-fork with guestmount - how do I know when the filesystem is actually mounted?  Previously I knew it was ready when it daemonized.

Comment 5 Richard W.M. Jones 2014-05-22 21:41:03 UTC
(In reply to Colin Walters from comment #4)
> I'm not sure how to use --no-fork with guestmount - how do I know when the
> filesystem is actually mounted?  Previously I knew it was ready when it
> daemonized.

From the raw API point of view, the mount point is ready to use
after calling guestfs_mount_local and before calling
guestfs_mount_local_run.  [See:
http://libguestfs.org/guestfs.3.html#mount-local ]

If you look at the implementation of guestmount:

https://github.com/libguestfs/libguestfs/blob/master/fuse/guestmount.c

then it's possible to tell when this has happened (either in the
forking or non-forking cases) because the PID file gets written out.

Therefore polling on existence of the PID file is the way to go.

If you really need a non-polling method, and you can't use the API
directly, then please open another RFE bug.


Note You need to log in before you can comment on or make changes to this bug.