Nagios Support Forum

scottwilkerson wrote:I'm going to have our Core developer take a look at this....

comment *find_comment(unsigned long comment_id, int comment_type) {
        comment *temp_comment = NULL;

        for(temp_comment = comment_list; temp_comment != NULL; temp_comment = temp_comment->next) {
                if(temp_comment->comment_id == comment_id && temp_comment->comment_type == comment_type)
                        return temp_comment;
                }

        return NULL;
        }

comment *find_comment(unsigned long comment_id, int comment_type) {
        comment *temp_comment = NULL;

        for(temp_comment = comment_list; temp_comment != NULL; temp_comment = temp_comment->next) {
                if(temp_comment->comment_id == comment_id)
                        return temp_comment;
                }

        return NULL;
        }

abrist wrote:If our C developer is in tomorrow, I will bring this post to his attention.

estanley wrote:There is definitely only one comment ID space, so a host and a service should never share a comment ID. Other than a rollover of the comment IDs at 2^32, there is only one case I can think of where you might get duplicate comment IDs and that is if core is restarted in the absence of the retention.dat file or the next_comment_id was not in the retention.dat file.

The retention data is read before the function xcddefault_initialize_comment_data() function is called. Only in the case where the next_comment_id was not set when the retention data was read would xcddefault_initialize_comment_data() do anything. As for the unused main_config_file parameter, I can only guess that maybe this function was at one time intended to be called through a function pointer and it is passed because there are (or were going to be) other initialization functions that would need the main configuration.

In the rest of the code, the next_comment_id is only ever incremented and it is specifically incremented after adding both host and service comments.

One caveat here, these conclusions come from reading the code, not executing it. The code is pretty straightforward so I don't think I've missed anything.

One possible solution to the poster's issue might be to shutdown core, manually edit the retention.dat file to set the next_comment_id above his highest known comment ID and restart. I would call that an unsupported solution, but it's worth a shot.

Hope that helps.

• Option 1: next_comment_id being reset back to 1. This is happening for us - we haven't been able to figure out why yet.
• Option 2: *find_comment from common/comments.cc is finding the next available comment_id to use only within the scope of hostcomments or servicecomments. I think this is what happens right now but could be compromised due to #1.
• Option 3: *find_comment from common/comments.cc should be finding the next available comment_id to use globally within all comments within the scope of hostcomments and servicecomments. I think this is what should be happening according to estanley's reply but could be compromised due to #1.

• Option 1: Suggests a Nagios issue to me. If this is the issue then there is something resetting next_comment_id back to 1 (or a low number). We have Nagios saving out the retention.dat file and we don't lose anything (host/service statuses) through restarts so I don't think we have any issues there. We've checked through restarts and the next_comment_id isn't changing - although it may be low due to whatever has happened to cause it to reset.
  Things that it could be:
  • Could it be related to the nightly rotating of log files. I'll try to log into our problem server tonight, stop Nagios, reset next_comment_id to the right number in the retention.dat file, start Nagios then watch what happens after midnight. I need to do this in the next 2 nights as we're installing my patched 3.4.4 (which removes the comment_type restriction in common/comments.cc: *find_comment as posted in http://support.nagios.com/forum/posting ... e3#pr46686) on Monday.
  • Could it be related to what is happening in option 2 - that is we're finding a low comment_id for the new comment we're adding which in turn is setting next_comment_id back to a low number?
• Option 2: Suggests a Livestatus issue to me. If this is the issue (duplicate comment_id's are OK only within the scope of hostcomments or servicecomments, not globally) then reusing comment_id's is valid and OK. As earlier, next_comment_id being reset is possibly compromising this and once we fix that this may not be an issue anymore.
• Option 3: Suggests a Nagios issue to me. If this is the issue (duplicate comment_id's are not OK and must be unique globally within the scope of hostcomments and servicecomments) then reusing comment_id's is bad and my patch is probably the right fix. As earlier, next_comment_id being reset is possibly compromising this and once we fix that this may not be an issue anymore.