From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:40353) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RmTLO-0000fk-4P for qemu-devel@nongnu.org; Sun, 15 Jan 2012 11:54:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RmTLM-0000bP-Qq for qemu-devel@nongnu.org; Sun, 15 Jan 2012 11:54:10 -0500 Received: from isrv.corpit.ru ([86.62.121.231]:47199) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RmTLM-0000bD-KA for qemu-devel@nongnu.org; Sun, 15 Jan 2012 11:54:08 -0500 Message-ID: <4F1304AD.202@msgid.tls.msk.ru> Date: Sun, 15 Jan 2012 20:54:05 +0400 From: Michael Tokarev MIME-Version: 1.0 References: <4F114A30.3070700@msgid.tls.msk.ru> <4F12CDAD.3070102@msgid.tls.msk.ru> <4F12FBFE.9070600@redhat.com> In-Reply-To: <4F12FBFE.9070600@redhat.com> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] qemu-nbd daemonizing? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: qemu-devel@nongnu.org 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