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

[Hanna Reitz]

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

> [...]
>
> > > Care to put a brief version of the rationale for --daemonize and for
> > > forking early in the commit message?
> > Well, my rationale for adding the feature doesn’t really extend beyond
> > “I want it, I find it useful, and so I assume others will, too”.
> Don't pretend to be obtuse, it's not credible :)  You mentioned iotests,
> which makes me guess your rationale is "I want this for iotests, and
> there may well be other uses."

Oh, I also want it for other things, like the script I have to use the 
QSD to make disk images accessible as raw files.  Thing is, the stress 
is on “want” in contrast to “need”.  I can do without --daemonize, I 
have already done so, even before there was --pidfile (I just queried 
the block exports through QMP until they were all there).  It’s just 
that it’s kind of a pain.

Same with the iotests, it’s absolutely possible to get away without 
--daemonize.  It’s just that I wrote the test, wanted to use some form 
of --daemonize option, noticed there wasn’t any yet, and thought “Oh, 
that’d be nice to have”.

I would love a --daemonize option, but I can’t say it’s necessary. If 
the way it’d need to be implemented isn’t acceptable, then I won’t force 
it into the code.

> > I don’t really like putting “qemu-nbd has it” there, because... it was
> > again me who implemented it for qemu-nbd.  Because I found it useful.
> > But I can of course do that, if it counts as a reason.
> Useful *what for*, and we have rationale.
>
> > I can certainly (and understand the need to, and will) elaborate on
> > the “This will require forking the process before we do any complex
> > initialization steps” part.
> Thanks!