[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] qemu-nbd daemonizing?
From: |
Michael Tokarev |
Subject: |
Re: [Qemu-devel] qemu-nbd daemonizing? |
Date: |
Sun, 15 Jan 2012 16:59:25 +0400 |
User-agent: |
Mozilla/5.0 (X11; Linux i686 on x86_64; rv:5.0) Gecko/20110805 Icedove/5.0 |
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