On 21.01.22 15:26, Markus Armbruster wrote:
Hanna Reitz <hre...@redhat.com> writes:
On 21.01.22 11:27, Markus Armbruster wrote:
Hanna Reitz <hre...@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.
