From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 21 07:45:59 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 DBB8C16A41F for ; Sun, 21 Aug 2005 07:45:59 +0000 (GMT) (envelope-from lists@nbux.com) Received: from smtp12.wanadoo.fr (smtp12.wanadoo.fr [193.252.22.20]) by mx1.FreeBSD.org (Postfix) with ESMTP id AAE7B43D48 for ; Sun, 21 Aug 2005 07:45:56 +0000 (GMT) (envelope-from lists@nbux.com) Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf1206.wanadoo.fr (SMTP Server) with ESMTP id 2F6441C000A3 for ; Sun, 21 Aug 2005 09:45:55 +0200 (CEST) Received: from daneel.nbux.com (LNeuilly-152-22-15-131.w82-127.abo.wanadoo.fr [82.127.94.131]) by mwinf1206.wanadoo.fr (SMTP Server) with ESMTP id 06AC21C000A0; Sun, 21 Aug 2005 09:45:54 +0200 (CEST) X-ME-UUID: 20050821074555274.06AC21C000A0@mwinf1206.wanadoo.fr Received: from [192.168.42.2] (daneel.nbux.com [192.168.42.2]) by daneel.nbux.com (Postfix) with ESMTP id 2EC0F1C32F0; Sun, 21 Aug 2005 09:45:54 +0200 (CEST) Message-ID: <43083131.4010407@nbux.com> Date: Sun, 21 Aug 2005 09:45:53 +0200 From: Christophe Yayon Organization: nbux.com User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Christophe Yayon References: <4306DA96.8000904@nbux.com> In-Reply-To: <4306DA96.8000904@nbux.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Daniel Eischen , 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: Sun, 21 Aug 2005 07:46:00 -0000 Hi again, I just upgraded again to FreeBSD5.4-Stable of August 20 and, i just killed a nagios loop process which consume 100% of CPU... The problem seems to persist again... How do think about this ? Thanks in advance. Christophe Yayon wrote: > Daniel, > > > But i am in stable '5.4-STABLE FreeBSD 5.4-STABLE #4: Tue Jul 5 > 11:18:14 CEST 2005' and i have again the problem ... > The post is from Jun 22... I don't understant why i have again the > problem ? > Could u help me, please ? > > Thanks. > > Daniel Eischen wrote: > >> 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. >> > > > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"