From owner-freebsd-hackers@FreeBSD.ORG Tue Jun 2 18:59:05 2009 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CE64B1065676; Tue, 2 Jun 2009 18:59:05 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [85.159.14.73]) by mx1.freebsd.org (Postfix) with ESMTP id C9FED8FC20; Tue, 2 Jun 2009 18:59:04 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from cicely5.cicely.de ([10.1.1.7]) by raven.bwct.de (8.13.4/8.13.4) with ESMTP id n52Ix2CG045303 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 2 Jun 2009 20:59:02 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by cicely5.cicely.de (8.14.2/8.14.2) with ESMTP id n52Iwpao077082 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Jun 2009 20:58:51 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.14.2/8.14.2) with ESMTP id n52Iwpis005467; Tue, 2 Jun 2009 20:58:51 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.14.2/8.14.2/Submit) id n52IwoFj005466; Tue, 2 Jun 2009 20:58:50 +0200 (CEST) (envelope-from ticso) Date: Tue, 2 Jun 2009 20:58:50 +0200 From: Bernd Walter To: Alfred Perlstein Message-ID: <20090602185850.GR1808@cicely7.cicely.de> References: <4A14F58F.8000801@rawbw.com> <4A1594DA.2010707@rawbw.com> <86ljoig08o.fsf@ds4.des.no> <20090528213017.GX67847@elvis.mu.org> <863aaow866.fsf@ds4.des.no> <20090529193137.GH67847@elvis.mu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090529193137.GH67847@elvis.mu.org> X-Operating-System: FreeBSD cicely7.cicely.de 7.0-STABLE i386 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-4.4 required=5.0 tests=ALL_TRUSTED=-1.8, BAYES_00=-2.599 autolearn=ham version=3.2.5 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on spamd.cicely.de Cc: Dag-Erling Sm??rgrav , freebsd-hackers@freebsd.org Subject: close-on-exec alternatives (was: Why kernel kills processes that run out of memory instead of just failing memory allocation system calls?) X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ticso@cicely.de List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 18:59:06 -0000 On Fri, May 29, 2009 at 12:31:37PM -0700, Alfred Perlstein wrote: > * Dag-Erling Sm??rgrav [090529 02:49] wrote: > > Alfred Perlstein writes: > > > Dag-Erling Sm??rgrav writes: > > > > Usually, what you see is closer to this: > > > > > > > > if ((pid = fork()) == 0) { > > > > for (int fd = 3; fd < getdtablesize(); ++fd) > > > > (void)close(fd); > > > > execve(path, argv, envp); > > > > _exit(1); > > > > } > > > > > > I'm probably missing something, but couldn't you iterate > > > in the parent setting the close-on-exec flag then vfork? > > > > This is an example, Alfred. Like most examples, it is greatly > > simplified. I invite you to peruse the source to find real-world > > instances of non-trivial fork() / execve() usage. > > It wasn't meant to critisize, just ask a question for the specific > instance because it made me curious. I know how bad it can be with > vfork as I observed a few fixes involving mistaken use of vfork at > another job. It is still very interesting, because I currently have a similar problem and wasn't aware of getdtablesize(); A threaded application which needs to call an external script of unknown runtime. I don't have all descriptors under my knowledge, because external libs might open them. I also believe there could be a race between retrieving the descriptor and setting close-on-exec. The only solution which I found so far is using rfork with RFCFDG. If I undestand RFCFDG correctly the child process has no descriptors at all. This is Ok for me, since I don't need to inherit some. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.