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 (http://marc.info/?l=nagios-devel&m=121251227708074). I think that would work but it's not an elegant solution. If you push a lot of comments through your system then the ~4.29 billion unsigned long int comment_id could potentially be used up (unlikely, but possible).scottwilkerson wrote:I'm going to have our Core developer take a look at this....
Looking at the nagios-3.4.4/common/comments.c file early this morning (seriously, why do I think best at 1am) I found this bit of code:
Code: Select all
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;
}
I've thought that to maintain global uniqueness then changing the above code to this may be a better more elegant solution for my immediate problem:
Code: Select all
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;
}
In the long term I am now happy that reusing unused comment_id's is actually a good thing and that this is probably a Livestatus bug with it not handing duplicate comment_id's and considering them as a globally unique identifier. I'll keep following up with them - and use the update I posted here in the meantime assuming I don't find any problems with it (I maintain our own internal Nagios packages so it's not a big deal to implement).
