Hanna Reitz <hre...@redhat.com> writes: > On 20.01.22 17:00, Markus Armbruster wrote: >> Kevin Wolf <kw...@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 <hre...@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). [...] >> 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." > 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!