From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:41036) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RmNk5-0001Fc-I0 for qemu-devel@nongnu.org; Sun, 15 Jan 2012 05:55:18 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RmNk4-0004dh-Av for qemu-devel@nongnu.org; Sun, 15 Jan 2012 05:55:17 -0500 Received: from lo.gmane.org ([80.91.229.12]:47602) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RmNk3-0004dc-V3 for qemu-devel@nongnu.org; Sun, 15 Jan 2012 05:55:16 -0500 Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1RmNjy-0001hB-BF for qemu-devel@nongnu.org; Sun, 15 Jan 2012 11:55:10 +0100 Received: from 93-34-200-238.ip51.fastwebnet.it ([93.34.200.238]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 15 Jan 2012 11:55:10 +0100 Received: from pbonzini by 93-34-200-238.ip51.fastwebnet.it with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 15 Jan 2012 11:55:10 +0100 From: Paolo Bonzini Date: Sun, 15 Jan 2012 11:51:17 +0100 Message-ID: References: <4F114A30.3070700@msgid.tls.msk.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit In-Reply-To: <4F114A30.3070700@msgid.tls.msk.ru> Subject: Re: [Qemu-devel] qemu-nbd daemonizing? List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org 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. 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. > - 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). > 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. Paolo