From owner-freebsd-hackers@FreeBSD.ORG Fri Aug 19 20:35:44 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 D045716A41F for ; Fri, 19 Aug 2005 20:35:44 +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 7073943D45 for ; Fri, 19 Aug 2005 20:35:44 +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 j7JKZhQU025028; Fri, 19 Aug 2005 16:35:43 -0400 (EDT) Date: Fri, 19 Aug 2005 16:35:43 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Christophe Yayon In-Reply-To: <43062603.5050206@nbux.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 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: Fri, 19 Aug 2005 20:35:44 -0000 On Fri, 19 Aug 2005, Christophe Yayon wrote: > Hi all > > You should know about freebsd and nagios 2.0b threads issues (100% cpu > use by a forked process, lost check result, some pause of nagios main > process in certains obscursives conditions...). > > Some Nagios developpers says that the problem is in FreeBSD and some > other says that the problem is in nagios pthreads implementation, here a > resume of our discussions : > From > > 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). They choose to quote a weak reference to the actual requirement. The standard says (in the fork() section): A process shall be created with a single thread. If a multi-threaded process calls fork(), the new process shall contain a replica of the calling thread and its entire address space, possibly including the states of mutexes and other resources. Consequently, to avoid errors, the child process may only execute async-signal-safe operations until such time as one of the exec functions is called. Fork handlers may be established by means of the pthread_atfork() function in order to maintain application invariants across fork() calls. -- DE