nagios and freebsd threads issue : help please ...

[Christophe Yayon]

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.
>