Re: [PATCH 1/3] qsd: Add pre-init argument parsing pass

[Hanna Reitz]

On 21.01.22 15:26, Markus Armbruster wrote:
> Hanna Reitz <hreitz@redhat.com> writes:
>
> > On 21.01.22 11:27, Markus Armbruster wrote:
> > > Hanna Reitz <hreitz@redhat.com> writes:
> > > > The problem I face is that currently there is no ergonomic way to wait
> > > > until the QSD is up and running (besides looping until the PID file
> > > > exists), and I don’t think a utility program that doesn’t know the QSD
> > > > could provide this.  (For example, it looks like daemonize(1) will
> > > > have the parent exit immediately, regardless of whether the child is
> > > > set up or not.)
> > > Why do you need to wait for QSD to be ready?
> > >
> > > I'm asking because with common daemons, I don't wait, I just connect to
> > > their socket and start talking.  They'll reply only when ready.
> > That only applies when you want to talk to a socket, which I often
> > don’t do.  Most of the time I use the storage daemon, I pass all
> > --blockdev and --export options through the command line and don’t
> >   create any socket at all.  When I use the QSD just to export some
> > block device, I generally don’t need QMP.
> If you export via NBD, why can't you just connect to NBD socket?

I’m not sure what exactly you mean by this, because the socket doesn’t 
exist before the QSD is launched.  If I launch the QSD in the background 
and have it create an NBD server on a Unix socket, then this socket will 
not exist until the respective --nbd-server option is parsed.  Trying to 
connect to it immediately after the QSD has been launched may work (if 
the QSD was quicker to parse the option and create the server than me 
trying to connect) or may yield ECONNREFUSED or ENOENT, depending on 
whether the socket file existed before or not.

Also, outside of the iotests, I personally generally usually use FUSE 
exports instead of NBD exports.