Hanna Reitz <hreitz@redhat.com> writes:
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.
This is similar to "with common daemons, [...] I just connect to their
socket and start talking."
Also, outside of the iotests, I personally generally usually use FUSE
exports instead of NBD exports.
You could wait for the mount to appear with stat -f.