From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 22 11:03:26 2005 Return-Path: X-Original-To: freebsd-hackers@freebsd.org Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id EB06016A41F for ; Mon, 22 Aug 2005 11:03:26 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from mail.ntplx.net (mail.ntplx.net [204.213.176.10]) by mx1.FreeBSD.org (Postfix) with ESMTP id D73CE43D96 for ; Mon, 22 Aug 2005 11:03:06 +0000 (GMT) (envelope-from deischen@freebsd.org) Received: from sea.ntplx.net (sea.ntplx.net [204.213.176.11]) by mail.ntplx.net (8.13.4/8.13.4/NETPLEX) with ESMTP id j7MB2vWX008329; Mon, 22 Aug 2005 07:02:58 -0400 (EDT) Date: Mon, 22 Aug 2005 07:02:57 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: "M. Warner Losh" In-Reply-To: <20050822.012017.22502074.imp@bsdimp.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: by AMaViS and Clam AntiVirus (mail.ntplx.net) Cc: freebsd-hackers@freebsd.org, lists@nbux.com Subject: Re: nagios and freebsd threads issue : help please ... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Daniel Eischen List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Aug 2005 11:03:27 -0000 On Mon, 22 Aug 2005, M. Warner Losh wrote: > In message: <43088841.4090709@nbux.com> > Christophe Yayon 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