nagios produces 100% cpu load

[McCann, Brian]

I'm getting the same thing, but I am running Nagios under daemontools
and thought that may be causing it.  Looks like I can rule that out now.
:)  I'm running it under FreeBSD 5.3 with ~330 checks and ~85 hosts.  Is
this perhaps related to the issue noted on the Nagios site about the
threading problem?

--Brian

-----Original Message-----
From: nagios-users-admin at lists.sourceforge.net
[mailto:nagios-users-admin at lists.sourceforge.net] On Behalf Of David
Elze
Sent: Wednesday, May 04, 2005 7:44
To: nagios-users at lists.sourceforge.net
Subject: [Nagios-users] nagios produces 100% cpu load

Hi, 

nagios 2.03b is working smoothly on a fairly simple configuration
(monitoring 5 systems in 3 different locations with about 6 services per
system) but after about 4 hours it (misab-)uses 100% CPU. If another
child process of nagios (i.e. a plugin) runs, the cpu usage is divided
so the nagios-related processes alltogether need 100% CPU.

I've configured max_concurrent_checks=5 but no effect. Everything is
running on OpenBSD (sparc64) in daemon-mode ('nagios -d') and the only 
warning I get when doing a 'nagios -v' is 'Warning: Size of 
service_message struct (528 bytes) is > POSIX-guaranteed atomic write 
size (512 bytes). Service checks results may get lost or mangled!'

If I kill-HUP the processes the high cpu usage remains the same as it is
the case if I try to restart the process(es) via the web interface. 

Thanks for any hint/rtfm/something

CU
  David



-------------------------------------------------------
This SF.Net email is sponsored by: NEC IT Guy Games.
Get your fingers limbered up and give it your best shot. 4 great events, 4
opportunities to win big! Highest score wins.NEC IT Guy Games. Play to
win an NEC 61 plasma display. Visit http://www.necitguy.com/?r 
_______________________________________________
Nagios-users mailing list
Nagios-users at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-users
::: Please include Nagios version, plugin version (-v) and OS when reporting any issue. 
::: Messages without supporting info will risk being sent to /dev/null