Another "Whoops! Error: Could not read object configura


About a week ago we decided to upgrade from Nagios 2.4 to 3.0 on a FreeBSD 6.2 server. Immediately upon updating we saw “Whoops! Error: Could not read object configuration data!” in the web interface. Everyone looked at it for about a day before deciding to just make a backup then delete the nagios directory (/usr/local/nagios) and reinstall 2.4 from source.
Nagios 2.4 was now acting up. It would carry out the first 5 or so host/service checks when it’s run, and then do nothing at all. Upon killing the process it would send a single notification for one of the hosts/services. Restarting would result in another 5 or so checks being carried out and then nothing. Again the decision was made to delete the nagios directory, but this time try installing 3.0 from source and trying to fix that problem. Currently Nagios 3.0rc2 is installed and using a stripped down version of my monitoring configuration (1 host, 5 services) but still showing “Whoops! Error: Could not read object configuration data!” whenever I try to view one of the CGIs. The nagios process is currently also using 99% CPU according to top.
/usr/local/nagios/bin/nagios -v /usr/local/nagios/etc/nagios.cfg brings up no errors or warnings, The permissions on all the cfg files appear to be correct (owned by nagios, rwrr for permissions). The nagios log shows no errors:

[1203525169] Nagios 3.0rc2 starting… (PID=93220)
[1203525169] Local time is Wed Feb 20 16:32:49 GMT 2008
[1203525169] LOG VERSION: 2.0
[1203525169] Finished daemonizing… (New PID=93221)

The apache log also shows no errors.
ps aux | grep nagios shows the process is running
nagios 93222 99.0 0.1 2356 1856 ?? R 4:32PM 1059:27.60 /usr/local/nagios/bin/nagios -d /usr/local/nagios/etc/nagios.cfg
nagios 93221 0.0 0.1 2348 1896 ?? Ss 4:32PM 0:09.96 /usr/local/nagios/bin/nagios -d /usr/local/nagios/etc/nagios.cfg

I’m stumped. Does anybody have any suggestions?


I’ve managed to solve the 99% CPU problem. I could not find a libmap.conf file so I created one in /etc and added the following:


This appears to have done the trick as far as CPU usage and host/service checks are concerned, although I’m still seeing the “Whoops! Error: Could not read object configuration data!” message in the web interface.