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

[Hanna Reitz]

On 21.01.22 11:27, Markus Armbruster wrote:
> Hanna Reitz <hreitz@redhat.com> writes:
>
> > On 21.01.22 07:10, Markus Armbruster wrote:
> > > Hanna Reitz <hreitz@redhat.com> writes:
> > >
> > > > On 20.01.22 17:00, Markus Armbruster wrote:
> > > > > Kevin Wolf <kwolf@redhat.com> writes:
> > > > >
> > > > > > Am 19.01.2022 um 14:44 hat Hanna Reitz geschrieben:
> > > > > > > On 19.01.22 13:58, Markus Armbruster wrote:
> > > > > > > > Hanna Reitz <hreitz@redhat.com> writes:
> > > > > > > >
> > > > > > > > > We want to add a --daemonize argument to QSD's command line.
> > > > > > > > Why?
> > > > > > > OK, s/we/I/.  I find it useful, because without such an option, I need to
> > > > > > > have whoever invokes QSD loop until the PID file exists, before I can be
> > > > > > > sure that all exports are set up.  I make use of it in the test cases added
> > > > > > > in patch 3.
> > > > > > >
> > > > > > > I suppose this could be worked around with a special character device, like
> > > > > > > so:
> > > > > > >
> > > > > > > ```
> > > > > > > ncat --listen -U /tmp/qsd-done.sock </dev/null &
> > > > > > > ncat_pid=$!
> > > > > > >
> > > > > > > qemu-storage-daemon \
> > > > > > >        ... \
> > > > > > >        --chardev socket,id=signal_done,path=/tmp/qsd-done.sock \
> > > > > > >        --monitor signal_done \
> > > > > > >        --pidfile /tmp/qsd.pid &
> > > > > > >
> > > > > > > wait $ncat_pid
> > > > > > > ```
> > > > > > >
> > > > > > > But having to use an extra tool for this is unergonomic.  I mean, if there’s
> > > > > > > no other way...
> > > > > I know duplicating this into every program that could server as a daemon
> > > > > is the Unix tradition.  Doesn't make it good.  Systemd[*] has tried to
> > > > > make it superfluous.
> > > > Well.  I have absolutely nothing against systemd.  Still, I will not
> > > > use it in an iotest, that’s for sure.
> > > My point isn't "use systemd in iotests".  It's "consider doing it like
> > > systemd", i.e. do the daemonization work in a utility program.  For what
> > > it's worth, Linux has daemonize(1).
> > 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.

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.)