[Xymon] disable requests not staying in place

Root, Paul Paul.Root at CenturyLink.com
Mon Nov 19 17:29:13 CET 2012


I believe the proxy would get the update and forward it back to the primary.

Paul Root    - Senior Engineer
Managed Services Systems - CenturyLink



> -----Original Message-----
> From: Raymond Lee [mailto:raylee88 at gmail.com]
> Sent: Monday, November 19, 2012 10:11 AM
> To: Ralph Mitchell
> Cc: Root, Paul; Carl Melgaard; xymon at xymon.com
> Subject: Re: [Xymon] disable requests not staying in place
> 
> On Mon, Nov 19, 2012 at 9:04 AM, Ralph Mitchell
> <ralphmitchell at gmail.com> wrote:
> > The xymondboard command returns the disable expiry time as -1 or a
> Unix
> > timestamp.  By default, the disable command expects a duration value
> in
> > minutes, but the man page for the xymon command says "If DURATION is
> given
> > as a number followed by s/m/h/d it is interpreted as being in
> > seconds/minutes/hours/days respectively."
> >
> > So, you ought to be able to pass back to xymon whatever lifetime
> value comes
> > from xymon, with "s" on the end.
> 
> 
> Yup, and that's what the bluesync.sh script was doing...subtracting
> the current Unix time (in seconds) from the disabletime returned by
> xymondboard (in seconds) and sending the disable to the secondary
> Xymon servers with a lifetime value ending in "s".
> 
> What's strange is that the bluesync.sh script running on the primary
> Xymon server doesn't issue any command such as `xymon localhost
> "disable host.test duration msg"`, and yet the disable time will drift
> on the primary Xymon server.  There's no other Xymon server that sends
> updates to the primary.
> 
> 
> Ray
> 
> >
> > What you *will* get with that expr command is lifetime rounded down
> to whole
> > minutes, so I would expect to see drift in that case.  E.g. if a
> disablement
> > has lifetime of 110 seconds, you'll be passing it along with a new
> lifetime
> > of 1 minute.
> >
> > Ralph Mitchell
> >
> >
> > On Mon, Nov 19, 2012 at 7:34 AM, Root, Paul
> <Paul.Root at centurylink.com>
> > wrote:
> >>
> >>
> >> Thanks,
> >>         Ray found that bluesync was the issue. He took it out and
> >> everything is working correctly now.
> >>
> >>         We'll check out this fix.
> >>
> >> Paul.
> >>
> >>
> >> Paul Root    - Senior Engineer
> >> Managed Services Systems - CenturyLink
> >>
> >>
> >> > -----Original Message-----
> >> > From: Carl Melgaard [mailto:Carl.Melgaard at stab.rm.dk]
> >> > Sent: Monday, November 19, 2012 1:27 AM
> >> > To: 'Raymond Lee'; Root, Paul
> >> > Cc: 'xymon at xymon.com'
> >> > Subject: SV: [Xymon] disable requests not staying in place
> >> >
> >> > Hi,
> >> >
> >> > I think I know whats happening, because I had the exact same
> problem on
> >> > 4.3.4 with bluesync :)
> >> >
> >> > The reason why the target date is moving, is because either Xymon
> or
> >> > bluesync calculates in seconds and the other does not - if I
> remember
> >> > correctly, I had to correct bluesync, so that it actually converts
> the
> >> > minutes from Xymon to seconds or visa versa.
> >> >
> >> > Something like this:
> >> >
> >> > NEW:           lifetime=`$EXPR ${lifetime} / 60`
> >> > OLD:           lifetime="$lifetime"s
> >> >
> >> > Regards,
> >> >
> >> > Carl Melgaard
> >> >
> >> > -----Oprindelig meddelelse-----
> >> > Fra: xymon-bounces at xymon.com [mailto:xymon-bounces at xymon.com] På
> vegne
> >> > af Raymond Lee
> >> > Sendt: 16. november 2012 17:26
> >> > Til: Root, Paul
> >> > Cc: xymon at xymon.com
> >> > Emne: Re: [Xymon] disable requests not staying in place
> >> >
> >> > Here's an example to describe what Paul & I are seeing on our
> Xymon
> >> > server.  Not only will the time-bound disables not stay in place,
> but
> >> > the "disabled until" date seems to be a moving target!
> >> >
> >> > Example:
> >> >
> >> > - I disabled a test that was red at Nov. 16 11:02 CST for 1 hour,
> and
> >> > the status page said "Disabled until Fri Nov 16 11:02:54 2012".
> So
> >> > that all looks fine.
> >> > - I checked the status page a little bit later, and it said
> "Disabled
> >> > until Sun Nov 18 17:58:06 2012".
> >> > - Yet a little while later, the status page said "Disabled until
> Thu
> >> > Apr 4 21:15:03 2013".
> >> > - Wait a little more, and it said "Disabled until Fri Oct 12
> 09:14:06
> >> > 2035"
> >> >
> >> > Eventually, the status page will say something crazy like
> "Disabled
> >> > until Fri Feb 17 18:40:58 1939", and then the color will turn to
> red
> >> > again.
> >> >
> >> > Has anyone else ever seen this behavior?
> >> >
> >> > Thanks,
> >> > Ray
> >> >
> >> >
> >> > On Tue, Nov 13, 2012 at 12:36 PM, Root, Paul
> >> > <Paul.Root at centurylink.com> wrote:
> >> > >
> >> > > We've been noticing that last week or two that requests for
> disabling
> >> > alerts for a set time do not stay blue. If we set it to 'until ok'
> they
> >> > will stay blue. Before the last few weeks, it had been fine.
> >> > >
> >> > >
> >> > > Our setup is a proxy updating the main system, due to firewall
> >> > issues.  I have installed 'bluesync.sh', that will send
> disable/enable
> >> > alerts down to the proxy.
> >> > >
> >> > > The machines are CentOS 5.8 virtual machines on VMWare ESXi 4.1
> >> > servers.  I'm running xymon 4.3.4.
> >> > >
> >> > > Any ideas.
> >> > >
> >> > >
> >> > > Paul Root    - Senior Engineer
> >> > > Managed Services Systems - CenturyLink
> >> > >
> >> > >
> >> > >
> >> > > _______________________________________________
> >> > > Xymon mailing list
> >> > > Xymon at xymon.com
> >> > > http://lists.xymon.com/mailman/listinfo/xymon
> >> > _______________________________________________
> >> > Xymon mailing list
> >> > Xymon at xymon.com
> >> > http://lists.xymon.com/mailman/listinfo/xymon
> >> _______________________________________________
> >> Xymon mailing list
> >> Xymon at xymon.com
> >> http://lists.xymon.com/mailman/listinfo/xymon
> >
> >



More information about the Xymon mailing list