Bug 112517 - pthread_atfork() handlers not called by system()
pthread_atfork() handlers not called by system()
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
athlon Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2003-12-21 20:59 EST by Jeff Epler
Modified: 2007-11-30 17:10 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-12-22 16:38:08 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jeff Epler 2003-12-21 20:59:29 EST
From Bugzilla Helper:
User-Agent: Mozilla/4.78 [en] (X11; U; Linux 2.4.7-10 i586)

Description of problem:
A handler installed by pthread_atfork() should be executed during a
call to system(), but it is not

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.Compile attached program "gcc pthread_bug.c -lpthread"
2.Execute it "./a.out"
3.Check exit status: 1 indicates presence of bug, 0 indicates absence
of bug

Actual Results:  Program exits with 1 because the global variable was
never modified by the pthread_atfork handler

Expected Results:  Program exits with 0 because the global variable
was modified by the pthread_atfork handler

Additional info:

This is the program:
#include <pthread.h>
#include <stdlib.h>

int g = 0;

void f(void) { g=1; }

int main(void) {
        pthread_atfork(f, NULL, NULL);
        return g==1 ? EXIT_SUCCESS : EXIT_FAILURE;
Comment 1 Jakub Jelinek 2003-12-22 03:53:54 EST
There is no word about system() in
and there doesn't seem to be anything in
that would mandate system() to be implemented using fork() function.
Comment 2 Jeff Epler 2003-12-22 08:01:11 EST
I base my claim that pthread_atfork() should be called by system()
from reading

The third paragraph under the heading "description" says this:
"[CX] The environment of the executed command shall be as if a child
process were created using fork(), and the child process invoked the
sh utility using execl() as follows [...]"

The rationale section expands on what the "environment of the executed
command" is:
"IEEE Std 1003.1-2001 places additional restrictions on system(). It
requires that if there is a command language interpreter, the
environment must be as specified by fork() and exec. This ensures, for
example, that close-on- exec works, that file locks are not inherited,
and that the process ID is different."

The pthread_atfork web page says it
"provides multi-threaded application programs with a standard
mechanism for protecting themselves from fork() calls in a library
routine or the application itself."
I believe that system() is one such library routine, since it is
specified to create an environment "as specified by fork()".

This issue arose in the context of Python.  For various reasons,
signals are blocked in all threads besides the main thread.  This
means that in processes generated by fork() from subthreads, all
signals are blocked, which leads to undesired behavior.  Using the
child argument of pthread_atfork() allows signals to be unblocked when
using fork()+exec() to execute an external program, but not when
system() is used.
Comment 3 Roland McGrath 2003-12-22 16:37:44 EST
I think it is clear that the specification refers to the elements of
the child process state that survive exec, so that the executed
command can perceive them as part of its "environment".  You could
submit an interpretation request, but I think the committee would
concur with my reading.  The specification of pthread_atfork refers to
calls to fork, not to other parts of the POSIX.1 implementation.  If
your application calls system, and not fork, those clauses do not
apply to it.

Note You need to log in before you can comment on or make changes to this bug.