Hanna Reitz <hre...@redhat.com> writes: > 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.
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.