Date: Mon, 22 Aug 2005 07:02:57 -0400 (EDT) From: Daniel Eischen <deischen@freebsd.org> To: "M. Warner Losh" <imp@bsdimp.com> Cc: freebsd-hackers@freebsd.org, lists@nbux.com Subject: Re: nagios and freebsd threads issue : help please ... Message-ID: <Pine.GSO.4.43.0508220654550.27356-100000@sea.ntplx.net> In-Reply-To: <20050822.012017.22502074.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 22 Aug 2005, M. Warner Losh wrote: > In message: <43088841.4090709@nbux.com> > Christophe Yayon <lists@nbux.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.43.0508220654550.27356-100000>