On 01/14/2012 10:26 AM, Michael Tokarev wrote:
After looking at the yesterdays issue with non-absolute
paths for qemu-nbd arguments and daemon(3), I've a
question.
Why qemu-nbd daemonizes, and does that only when device
argument is given (dropping -v/verbose case for now)?
This raises two questions:
- shouldn't it do the same daemonizing in case of usual
tcp export?
Perhaps yes, but in that case you cannot use "qemu-nbd -d" to kill the
daemonized process. Also, one of the best things of systemd is that it
handles daemonization on its own, so nowadays it is better not to have
process send themselves into background by default.
- shouldn't the daemonizing itself be controlled by an
option (like -d), and why we can't just send it to
background using "&" shell constuct?
Daemonization does more than "&" (the double fork+setsid process).
And while at it, I wonder why it is really unix-only?
There's nothing unix-specific in there exept two things:
it is the device handling (/dev/nbdX) and all the hacks
around this (including this daemonizing). The rest should
work on win32 just fine.
I think it's just historical.
Paolo
