--_004_40FF3EB574329C459B49338F779CE44E01793692F6bosmail2k7adv_
Content-Type: multipart/alternative;
boundary="_000_40FF3EB574329C459B49338F779CE44E01793692F6bosmail2k7adv_"
--_000_40FF3EB574329C459B49338F779CE44E01793692F6bosmail2k7adv_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
If a host or service is found to be flapping when state is read in during s=
tartup in xrddefault.c, then a new comment about the flapping is added to t=
he system.
Since this happens before all of retention.dat has been read in, the commen=
t ID assigned to this new comment could conflict with a comment ID of an ex=
isting comment later in retention.dat.
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, i=
t gets assigned a duplicate comment ID. D'oh!)
A comment ID changing when Nagios restarts can cause problems if comment ID=
s 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 h=
ave a page with a comment on it displayed in my browser, and then the Nagio=
s server restarts, and then I try to remove the comment and it has been ren=
umbered, 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 kno=
w how much larger than that the scope of the problem is.
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 uncomforta=
ble in a "boy, that's gross, that can't possibly be the correct fix" sort o=
f way. The fix I have in mind depends on the facts that (a) only persisten=
t comments will be read from retention.dat on startup, and (b) flapping com=
ments are non-persistent. So what I'm thinking is that we should allow dup=
licate 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 li=
st 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 sa=
id, that's really gross, but I think it will do the right thing.
Thoughts?
Jonathan Kamens
Operations Manager
[cid:[email protected]]
201 South Street, Suite 300, Boston, MA 02111
Phone: +1 617 261 0264 ext. 133 | Mobile : +1 617 417 8989 | Fax: + 1 617 8=
12 0330
[email protected] | www.advent.com
--_000_40FF3EB574329C459B49338F779CE44E01793692F6bosmail2k7adv_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
<!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Tahoma;
panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underlin
...[email truncated]...
This post was automatically imported from historical nagios-devel mailing list archives
Original poster: [email protected]