Red Hat Bugzilla – Bug 112517
pthread_atfork() handlers not called by system()
Last modified: 2007-11-30 17:10:34 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): glibc-2.3.2-101.1 How reproducible: Always 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); system("true"); return g==1 ? EXIT_SUCCESS : EXIT_FAILURE; }
Why? There is no word about system() in http://www.opengroup.org/onlinepubs/007904975/functions/pthread_atfork.html and there doesn't seem to be anything in http://www.opengroup.org/onlinepubs/007904975/functions/system.html that would mandate system() to be implemented using fork() function.
I base my claim that pthread_atfork() should be called by system() from reading http://www.opengroup.org/onlinepubs/007904975/functions/system.html 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.
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.