Re: [Qemu-devel] qemu-nbd daemonizing?

[Michael Tokarev]

On 15.01.2012 20:17, Paolo Bonzini wrote:
> On 01/15/2012 01:59 PM, Michael Tokarev wrote:
>> 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.
> 
> No, "qemu-nbd -d" will connect to the /dev/nbdX device and tell the kernel to 
> disconnect.  This will terminate the daemon (as long as you didn't use 
> --persistent, at least).

Whatever.  In any case qemu-nbd is able to terminate currently
running daemon, nothing changes with addition daemonizing here
or without - that was my point.

>>> 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
> 
> --verbose is a counterintuitive way not to daemonize, but it works.

I know it works (with additional bonus - it shows extra messages).
It wasn't my question.

>> The primary question was why -c daemonizes unconditionally.
> 
> I don't know.  But I don't think daemonizing is really a feature, just 
> something historical that we have to deal with.

Aha.  So can't it just go away, or be controlled by another
option, not related to -c ?  I think it should be good.

>> 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.
> 
> Fixing it would be good indeed.  We can use qemu-thread for that for example. 
>  But it looks like the third commit ever to qemu-nbd.c already made it 
> non-Linux-only.  I don't think there ever was a release that supported 
> qemu-nbd on Win32, right?

It is kinda trivial to fix this.  But this task becomes
completely unrealistic if that will involve another
discussion like we currently have.

Thanks,

/mjt