close-on-exec alternatives (was: Why kernel kills processes that run out of memory instead of just failing memory allocation system calls?)

On Fri, May 29, 2009 at 12:31:37PM -0700, Alfred Perlstein wrote:
* Dag-Erling Sm??rgrav <des@xxxxxx> [090529 02:49] wrote:
Alfred Perlstein <alfred@xxxxxxxxxxx> writes:
Dag-Erling Sm??rgrav <des@xxxxxx> 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@xxxxxxx> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.
_______________________________________________
freebsd-hackers@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@xxxxxxxxxxx"

Relevant Pages