Nagios Support Forum

We do have our mysql server offloaded to a separate server, our nagios server did have mysql running on it initially and it was still running( shut off now) I'm wondering if the write config function in the new ccm was using the local copy in place of the offloaded db??? yesterday I did rerun applyconfig from the command line and then had to delete the 1000 or so hosts with the later time stamp and restart nagios, its fine now.

can I email you the running config instead, I don't really want to put it on the forum.

Are you still experiencing the really long restart times?

Can you post the output from the following command?
If you haven't already you can email the config snapshot to [email protected].

-rw------- 1 nagios users 24233807 Dec 18 10:05 /usr/local/nagios/var/retention.dat

Yeah the restarts seem to take a while, it appears that gearman is running and processing the checks during that time however so I have never really concerned myself with it. My biggest worry about the apply taking so long is the possibility of it timing out and leaving our configuration files in an inconsistent state.... I noted in the database that the last update time is saved with the record, is there anyway to have an option in apply config that would do an incremental update option(i.e. only write files for those records that have changed)????

One thing to note is that when I actually do a system reboot nagios starts up quick and all the checkmarks are green, but I have to actually restart the nagios services after that because the hosts load but they show up in the interface as grey instead of green(i.e. notifications disabled)

is there anyway to have an option in apply config that would do an incremental update option(i.e. only write files for those records that have changed)????

I tinkered with this about a month ago, and the idea of it works really well until an object gets renamed, then everything needs to get updated in order for the config to work correctly. We haven't yet devised a good solution to make sure we always catch if an object gets renamed, so at the moment we haven't implemented this.

One thing to note is that when I actually do a system reboot nagios starts up quick and all the checkmarks are green, but I have to actually restart the nagios services after that because the hosts load but they show up in the interface as grey instead of green(i.e. notifications disabled)

That is unusual. You might try deleting the retention.dat file one time and seeing if that clears the issue. Note that this will put all of your objects in a pending state until the new status is determined for all hosts and services.

I do have objects.cache and status.dat on a ramdisk, therefore a reboot destroys those files, would that possibly create an issue with retention.dat?

paul.jobb wrote:I do have objects.cache and status.dat on a ramdisk, therefore a reboot destroys those files, would that possibly create an issue with retention.dat?

It shouldn't, but the retention.dat if exists is loaded on nagios restart.

We can force a state reset by stopping nagios removing retention.dat and then restarting nagios.

As mguthrie mentioned

mguthrie wrote:Note that this will put all of your objects in a pending state until the new status is determined for all hosts and services.

yes that will be my next step.

I had what seemed to be some erroneous settings in my /etc/sysctl.conf file which I have reset and matched these settings on my mysql server also

kernel.msgmnb = 131072000
#kernel.msgmnb = 4294967295
kernel.msgmax = 131072000
#kernel.msgmax = 4294967295
kernel.shmmax = 4294967295
kernel.shmall = 268435456
kernel.msgmni = 256000

Did you try stopping nagios, removing retention.dat and then restarting nagios? Is the issue resolved?

Reading the nagiosql forum I kind of get them impression with the latest release(3.2) that it only does write out the host/service records that change???

Have you tried as Ludmil suggested? Stopping naigos then removing the retetention.dat file?