nagios and freebsd threads issue : help please ...
Daniel Eischen
deischen at freebsd.org
Fri Aug 19 20:35:44 GMT 2005
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
More information about the freebsd-hackers
mailing list