Nagios Support Forum

And ~24 hours later next_comment_id still hasn't reset so I am more confident that's what was causing it. After talking to somebody here, we now know why we set this to 0 (it was so that when we synced the config and retention information to DR we could set enable_notifications to 0 in nagios.cfg an...

So .. you're not allowed to laugh at us here .. OK? Anyway, you know this particular entry in the nagios.cfg file: # USE RETAINED PROGRAM STATE # This setting determines whether or not Nagios will set # program status variables based on the values saved in the # retention file. If you want to use re...

Hmmmm ... more to think about. Just to respond to the "reset the next_comment_id", we have and once restarted the status.dat file shows that number .. but some process still resets it. More on this in the post. It sounds like there are possibly a few things that could be the issue here the...

Brilliant. Thanks muchly. I suspect that as Mathias is at CeBit he probably hasn't had time to look at my emailed bug report yet (the mailing list, at least the English version, looked more a user support list rather than an interact with the devs list so wasn't much help at all). I'll keep followin...

Ah ok, cheers. My patch is only a temporary hacky work around for Livestatus on my end rather than something I consider needing to be fixed in Nagios which is why I don't really want to submit a bug report as I'm about 99.99% sure that Nagios isn't doing anything wrong by not treating comment_id as ...

If our C developer is in tomorrow, I will bring this post to his attention. Sorry, I don't mean to sound like I'm hassling, just wondering if there was any news. We were lucky and got to try our patched version in production (had to fail over from prod to DR due to a network fault) and my small pat...

I'm going to have our Core developer take a look at this.... Cheers. I've been doing a fair bit of thinking about this in the last few days - and have tried a patch which doesn't rely on next_comment_id and instead sets this number based on the highest comment_id found in the retention.dat file + 1...

No problem. If you could add that to your post on the mk list that would be great, I am sure they will get the bug sorted soon... Done. What's confusing me is that there is only 1 next_comment_id stored in the status.dat and retention.dat files, however when adding a comment it calls xcddefault_add...

This appears that livestatus isn't taking into account the comment_type comment_type =Indicates whether this is a host or service comment 1 = Host comment 2 = Service comment So it is very possible to have 2 comment_id's that are the same with different comment_type's Yep, I was wondering if it was...

Good to know, keep us updated. You may want to report your findings to the mk community as well. This is what I posted there yesterday: http://lists.mathias-kettner.de/pipermail/checkmk-en/2013-February/008628.html The issue looks to be that Nagios can create a hostcomment and a servicecomment that...