Date: Sat, 20 Aug 2005 09:24:06 +0200 From: Christophe Yayon <lists@nbux.com> To: Daniel Eischen <deischen@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: nagios and freebsd threads issue : help please ... Message-ID: <4306DA96.8000904@nbux.com> In-Reply-To: <Pine.GSO.4.43.0508191630140.12955-100000@sea.ntplx.net> References: <Pine.GSO.4.43.0508191630140.12955-100000@sea.ntplx.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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. >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4306DA96.8000904>