<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv=Content-Type content="text/html; charset=us-ascii"> <meta name=Generator content="Microsoft Word 12 (filtered medium)">  <style>  </style>  </head> <body lang=EN-US link=blue vlink=purple> <div class=Section1> If a host or service is found to be flapping when state is read in during startup in xrddefault.c, then a new comment about the flapping is added to the system.<o:p></o:p> <o:p> </o:p> Since this happens before all of retention.dat has been read in, the comment ID assigned to this new comment could conflict with a comment ID of an existing comment later in retention.dat.<o:p></o:p> <o:p> </o:p> Then, when that later comment is read in, it gets assigned a new comment ID. (Or, if you're using my recently submitted startup time speed-up patch, it gets assigned a duplicate comment ID. D'oh!)<o:p></o:p> <o:p> </o:p> A comment ID changing when Nagios restarts can cause problems if comment IDs are being stored and used in a persistent fashion anywhere outside of the Nagios process itself. One way I know that happens is in the CGI. If I have a page with a comment on it displayed in my browser, and then the Nagios server restarts, and then I try to remove the comment and it has been renumbered, I'll end up removing the wrong comment. I don't know how else, if at all, comment IDs are used outside of the Nagios process, so I don't know how much larger than that the scope of the problem is.<o:p></o:p> <o:p> </o:p> I have been trying, unsuccessfully, to think of a good fix for this problem. I've thought of a fix that I think will work, but it makes me uncomfortable in a "boy, that's gross, that can't possibly be the correct fix" sort of way. The fix I have in mind depends on the facts that (a) only persistent comments will be read from retention.dat on startup, and (b) flapping comments are non-persistent. So what I'm thinking is that we should allow duplicate comment IDs to be created when adding flapping comments (as my patch does), and then when we're done reading retention.dat, scan through the list of comments (after sorting it), find duplicates, and when a duplicate is found, renumber the one that isn't marked persistent (since when there are duplicates, exactly one of them will always be non-persistent). Like I said, that's really gross, but I think it will do the right thing.<o:p></o:p> <o:p> </o:p> Thoughts?<o:p></o:p> <o:p> </o:p> Jonathan Kamens Operations Manager<o:p></o:p> <a href="http://www.advent.com/solutions/by-product/tamale-rms"><img border=0 width=190 height=34 id="Picture_x0020_1" src="cid:image001.jpg@01CAA346.063475E0" alt="Advent Tamale RMS"></a><o:p></o:p> 201 South Street, Suite 300, Boston, MA 02111 Phone: +1 617 261 0264 ext. 133 | Mobile : +1 617 417 8989 | Fax: + 1 617 812 0330 <a href="mailto:jkamens@advent.com" title="mailto:jkamens@advent.com">jkamens@advent.com</a> | <a href="http://www.advent.com/" title="http://www.advent.com/">www.advent.com</a><o:p></o:p> <o:p> </o:p> </div> </body> </html>