Date: Fri, 6 May 2005 15:09:49 -0400 (EDT) From: Daniel Eischen <deischen@freebsd.org> To: Christophe Yayon <lists@nbux.com> Cc: freebsd-stable@freebsd.org Subject: Re: pthreads and nagios issue Message-ID: <Pine.GSO.4.43.0505061506010.12649-100000@sea.ntplx.net> In-Reply-To: <50660.192.168.0.20.1115406166.squirrel@webmail.nbux.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 6 May 2005, Christophe Yayon wrote: > Hi, > > But is it a Nagios or FreeBSD problem, if you read "what's new" section on > nagios site, you can see : > ----------------- > FreeBSD and threads. On FreeBSD there's a native user-level implementation > of threads called 'pthread' and there's also an optional ports collection > 'linuxthreads' that uses kernel hooks. Some folks from Yahoo! have > reported that using the pthread library causes Nagios to pause under heavy > I/O load, causing some service check results to be lost. Switching to > linuxthreads seems to help this problem, but not fix it. The lock happens > in liblthread's __pthread_acquire() - it can't ever acquire the spinlock. > It happens when the main thread forks to execute an active check. On the > second fork to create the grandchild, the grandchild is created by fork, > but never returns from liblthread's fork wrapper, because it's stuck in > __pthread_acquire(). Maybe some FreeBSD users can help out with this > problem. > ------------------ > And it appears to be a FreeBSD pthread implementation problem (not a > Nagios specific problem...) > What do u think about that ? Re-read what is written above. __pthread_acquire() is in liblthread; that is linuxthreads and not a POSIX function. The reported FreeBSD pthread problem above is a "pause under heavy I/O load...". I'm not sure what could cause that -- need more info. -- DE
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.43.0505061506010.12649-100000>