On 15.01.2012 14:51, Paolo Bonzini wrote: > 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.
Sorry? qemu-nbd -d will connect to the socket the daemonized daemon is listening on, the same way as it is done now -- nothing really changes there. > 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. First, not all the world is systemd. Second, my question was merely about consistency -- -c does daemonizing currently and there's no way to stop it from doing so, regular tcp case does not do any daemonizing. >> - 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). Sure. We've setsid and shell redirection for that if you wish. The primary question was why -c daemonizes unconditionally. >> 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. qemu-nbd was runnable on win32 before, so historically it was exactly the opposite. I asked you because you mentioned it is linux-only for the first time, but indeed, at that time it wasn't compilable on win32 already. Thanks, /mjt
