From owner-freebsd-hackers@FreeBSD.ORG Mon Aug 22 07:21:00 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 966E216A41F; Mon, 22 Aug 2005 07:21:00 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from harmony.village.org (vc4-2-0-87.dsl.netrack.net [199.45.160.85]) by mx1.FreeBSD.org (Postfix) with ESMTP id F0ABD43D55; Mon, 22 Aug 2005 07:20:59 +0000 (GMT) (envelope-from imp@bsdimp.com) Received: from localhost (localhost.village.org [127.0.0.1]) by harmony.village.org (8.13.3/8.13.3) with ESMTP id j7M7KA7k041796; Mon, 22 Aug 2005 01:20:10 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Mon, 22 Aug 2005 01:20:17 -0600 (MDT) Message-Id: <20050822.012017.22502074.imp@bsdimp.com> To: lists@nbux.com From: "M. Warner Losh" In-Reply-To: <43088841.4090709@nbux.com> References: <43088841.4090709@nbux.com> X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-2.0 (harmony.village.org [127.0.0.1]); Mon, 22 Aug 2005 01:20:10 -0600 (MDT) Cc: deischen@freebsd.org, freebsd-hackers@freebsd.org Subject: Re: nagios and freebsd threads issue : help please ... X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list 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 07:21:00 -0000 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. Looks complicated to actually setup, but in my experience, popen + threads is asking for trouble. Warner