On Wed, Jan 16, 2002 at 08:34:09AM -0500, Tuc wrote:
> > > Hi,
> > >
> > > We just brought our system up, and are seeing alot of :
> > >
> > > Warning - Tue Jan 15 12:40:10 2002 [hostmon]: DEVICE l.ttsg.com
> > > l.ttsg.com VAR DataAge 366 900 Secs LEVEL Warning LOGLEVEL Warning STATE
> > > down
> >
> > The DataAge issue, if memory serves, says that the variable hasn't been
> > updated for the last three (?) interations/deltas (think that's like 30
> > minutes with hostmon).
> >
> I look at the file, and it looks like its been updated, atleast
> the timestamp was. And isn't 366 less than 900, so it shouldn't alarm ?
That might be an error or a mis-nomer (perhaps Vikas can clarify - I've
not looked that closely at this code yet); think the "dataage" failure
may start closer to 0 when it's first triggered? (In any case, I think
this isn't terribly well documented, etc, at this point)
> > Think this will go away if the hostmon-client is
> > started on the machine in-quesiton and the box running hostmon-collector
> > is able to get to the control port or copy down the correct data (either
> > via rcp or scp or whatever).
>
> Its running, its available, its answering requests for other
> programs that query it. The timestamp on the file in the /tmp/hostmon_data
> directory keeps changing...
Hmmm... I saw something very similiar here, too, at some point (and I
forget what I did to make it go away or if it "just did") -- that is,
basically I could telnet in to the port from the hostmon-collector side
and see everything, but hostmon wasn't picking it up yet was still
complaining about the "Data Age."
> > Also... although keepalive-monitors, by default, likes to try to start
> > the hostmon process, I do not believe that it starts the client (we're
> > talking out-of-the-box config, etc).
> >
> Understood.
> >
> > Hope that helps...
> >
> Nope. I put extra debug in, and it didn't help me understand.
>
> Between this, and a few other things, we backed out SNIPS and
> went back to Nocol. Is this a reflection of the production version of
> SNIPS?
>
> Tuc/TTSG Internet Services, Inc.
Well, there's always the premise of never running an even-numbered or
zeroed release in production, but... yeah, I'd certainly agree with you
(amny changes this time (which is overall a good thing), but also a lot
more "weird" things compared to previous releases (perhaps it's just
that we're well-familiar with the "tweaks" for those now).
Russell
--
Russell M. Van Tassell
russell at loosenut com
"Windows 95: n. 32 bit extensions and a graphical shell for a 16 bit patch
to an 8 bit operating system originally coded for a 4 bit microprocessor,
written by a 2 bit company that can't stand 1 bit of competition."
- Gnu-Win32/CygWin32 FAQ (http://www.cygnus.com/misc/gnu-win32)
|