nagios and freebsd threads issue : help please ...

[Christophe Yayon]

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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"