nagios and freebsd threads issue : help please ...

[Daniel Eischen]

On Mon, 22 Aug 2005, M. Warner Losh wrote:

> In message: <43088841.4090709 at nbux.com>
>             Christophe Yayon <lists at 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