qemu-devel
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]