From owner-freebsd-hackers@FreeBSD.ORG Sun Aug 21 13:45:24 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 8154416A41F for ; Sun, 21 Aug 2005 13:45:24 +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 286E543D48 for ; Sun, 21 Aug 2005 13:45:24 +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 j7LDjMqm006589; Sun, 21 Aug 2005 09:45:23 -0400 (EDT) Date: Sun, 21 Aug 2005 09:45:22 -0400 (EDT) From: Daniel Eischen X-X-Sender: eischen@sea.ntplx.net To: Christophe Yayon In-Reply-To: <43083131.4010407@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: Sun, 21 Aug 2005 13:45:24 -0000 On Sun, 21 Aug 2005, Christophe Yayon wrote: > 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. Go ask the nagios guys. If they are doing things after a fork() from a threaded application that are not allowed by POSIX, then they need to address it. > >> 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