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? > Of course, I could just not do that, and instead only set up QMP and > then do all the configuration through that (where, as you say, QSD > will only reply once it can); but that’s much more complicated than > running a single command. > > (Or I could do a mix of both, which I described above, where I’d > create and have the QSD connect to a Unix socket just to see that > configuration is done and all exports are up. I’d prefer not to, > because it still means using an extra tool (ncat) to create the > socket.)