On Mon, 22 Aug 2005, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > Christophe Yayon <[EMAIL PROTECTED]> writes: > : http://www.opengroup.org/onlinepubs/009695399/functions/pthread_atfork.html > : > : "It is suggested that programs that use fork() call an exec function > : very soon afterwards in the child process, thus resetting all states. In > : the meantime, only a short list of async-signal-safe library routines > : are promised to be available." > : > : Note *suggested*. This is a recommendation to protect against a shoddy > : pthread-implementation. The thread specifications rule that only the > : thread calling fork() is duplicated, which initially leads to the > : recommendation (other threads holding locks aren't around to release > : them in the new execution context). > > Here's what nagios does after a fork: > > in base/util.c: > > (1) Become the process group leader by calling setpgid(0, 0); > (2) something called set_all_macro_environemt_vars(TRUE). > This calls snprintf a bunch, as well as set variables > by saving them to malloced memory. This save is done > with strcpy and strcat. setenv is then called to try to > export them. memory is then freed with free(3). > (3) All signal handlers are reset > (4) The right part of the pipe is closed > (5) sigalarm handler is created and an alarm set. > (6) Checks to see if it executing an embedded perl script, > then tries to execute it if so. This has the feel of > being too much after the fork. > (7) Calls popen on the command if not. > (8) Reads the output of the command using fgets. > (9) closes the other end of the pipe > (10) unsets all env vars. > (11) Calls _exit() > > > in base/checks.c > > (1) set_all_macro_environment_vars(TRUE) > (2) forks again > (3) granchild: > resets handler, setpgid, etc. > if perl script, do embedded perl, otherwise popen. > lots of read/write to pipe. > > likewise in base/commands.c fork is also called for similar > things. > > There's other places that also call popen. > > So, if any of these things is an issue, and you can point to a posix > things that says it is an issue, then I think that the problem can be > resolved.
You can only execute async-signal-safe functions after a fork() from a threaded application. free(), malloc(), popen(), fgets(), are not async-signal-safe. The list of async-signal-safe functions are here: http://www.opengroup.org/onlinepubs/009695399/nframe.html The restriction on fork() is here (20th bullet down): http://www.opengroup.org/onlinepubs/009695399/nframe.html -- DE _______________________________________________ [email protected] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
