Re: [PATCH] qemu-nbd: Document benefit of --pid-file

[Daniel P . Berrangé]

On Tue, Oct 08, 2019 at 08:28:16AM -0500, Eric Blake wrote:
> On 10/8/19 4:40 AM, Vladimir Sementsov-Ogievskiy wrote:
> > 08.10.2019 12:24, Daniel P. Berrangé wrote:
> > > On Mon, Oct 07, 2019 at 02:48:40PM -0500, Eric Blake wrote:
> > > > One benefit of --pid-file is that it is easier to probe the file
> > > > system to see if a pid file has been created than it is to probe if a
> > > > socket is available for connection. Document that this is an
> > > > intentional feature.
> > > 
> > > I'm not seeing how checking the pid file is better than checking
> > > the socket directly ? I think it is probably actually worse.
> > > 
> > > The main problem with the socket is that while we unlink on clean
> > > shutdown, it may still exist in disk if the process has exitted
> > > abnormally.
> > > 
> > > With the pidfile though we don't ever unlink it, even on clean
> > > shutdown, as we don't use the pid files existance as a mutual
> > > exclusion check. We instead acquire fcntl locks on it.
> > > 
> > > IOW the pidfile could exist already when qemu-nbd starts up and
> > > will still exist when it quits.
> > 
> > Good point.
> > 
> > I was just a bit confused, because pid file is something unrelated to
> > socket, and why use one thing to check the existence of another, if we
> > can directly try to connect.
> 
> Consider the case of writing a testsuite that involves an nbd client, where
> you want to fire up qemu-nbd as the server.  Checking for a pid file in
> shell is easy, and can be done prior to the point of spawning a client.
> Checking for a successful connect is harder - the shell is not the point
> that would actually connect, so checking if connect works involves the shell
> actually spawning off the child process that attempts the connect.  If the
> client itself has a retry builtin, then you don't need to do anything in
> shell - just spawn the client with retry (at which point, the client
> retrying on the connection is smarter than the client retrying on the pid
> file).  But pid files are immensely useful when you have a client that does
> not have builtin retry, and when writing a testing framework where you use
> shell to learn whether it is safe to spawn the client: rather than having to
> modify the client or write a shell loop that respawns child attempts, you
> merely need a shell loop probing for the pid file to exist.

We shouldn't need todo any of those tricks IIUC.  The --fork argument is
supposed to only let the parent process exit once the server is running.

IOW, if you run qemu-nbd --fork, in the foreground, then when execution
continues the sockets should be present & accepting connections. No need
to check for existance of any files or check connecting, etc.


Except that AFAICT, --fork isn't actually implemented with this semantics
in qemu-nbd. It looks like we only listen on the sockets after the parent
has already exited :-( Can we fix that to synchronize wrt socket listeners ?

Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|