On Thu, Sep 29, 2016 at 02:18:54PM +0200, Paolo Bonzini wrote: > > > On 29/09/2016 13:13, Daniel P. Berrange wrote: > > On Thu, Sep 29, 2016 at 02:02:15PM +0300, Denis V. Lunev wrote: > >> From: Denis Plotnikov <dplotni...@virtuozzo.com> > >> > >> Originally NBD server socket was created by qemu-nbd code. This leads to > >> the race when the management layer starts qemu-nbd server and allows a > >> client to connect to the server. In this case there is a possibility that > >> qemu-nbd does not open listening server socket yet. Creating listening > >> socket before starting of qemu-ndb and passing socket fd via command line > >> solves this issue completely. > > > > FWIW, this could be solved in qemu-nbd itself if we had a general > > ability to request "daemon" mode - currently it only daemonizes > > if attaching to a nbd block device. > > > > The key would be that qemu-nbd would open the listening socket > > before daemonizing. Thus when the mgmt application spawned > > qemu-nbd in daemon mode, it can be sure that the listener > > socket is present when waitpid() completes. > > This is 100% true, but I find daemonization to be a hack, so file > descriptor passing has its place. > > Still, I'd prefer to have a --socket-activation option which uses the > systemd socket activation protocol. The systemd protocol can be > implemented easily by any management layer.
That's a nice idea - system socket activation is pretty simple todo Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|
