Bug 916780

Summary:	feature request: guestmount --with-cleanup-pipefd
Product:	[Community] Virtualization Tools	Reporter:	Colin Walters <walters>
Component:	libguestfs	Assignee:	Richard W.M. Jones <rjones>
Status:	CLOSED UPSTREAM	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	unspecified	CC:	dyasny, mbooth
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-03-05 13:54:36 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

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 3 Richard W.M. Jones 2013-03-05 14:48:20 UTC

Also:

https://github.com/libguestfs/libguestfs/commit/0120a087f444d3ebeb16b96696b993684db550db
https://github.com/libguestfs/libguestfs/commit/603968934423041757e9e4cf75419b184cec1698

(Both included in 1.21.17)

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.