Date: Tue, 2 Jun 2009 20:58:50 +0200 From: Bernd Walter <ticso@cicely7.cicely.de> To: Alfred Perlstein <alfred@freebsd.org> Cc: Dag-Erling Sm??rgrav <des@des.no>, 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?) Message-ID: <20090602185850.GR1808@cicely7.cicely.de> In-Reply-To: <20090529193137.GH67847@elvis.mu.org> References: <4A14F58F.8000801@rawbw.com> <Pine.GSO.4.64.0905202344420.1483@zeno.ucsd.edu> <4A1594DA.2010707@rawbw.com> <86ljoig08o.fsf@ds4.des.no> <20090528213017.GX67847@elvis.mu.org> <863aaow866.fsf@ds4.des.no> <20090529193137.GH67847@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, May 29, 2009 at 12:31:37PM -0700, Alfred Perlstein wrote:
> * Dag-Erling Sm??rgrav <des@des.no> [090529 02:49] wrote:
> > Alfred Perlstein <alfred@freebsd.org> writes:
> > > Dag-Erling Sm??rgrav <des@des.no> 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 <bernd@bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20090602185850.GR1808>