[mrtg] Re: enhancement suggestion

[Jason Frisvold]

Now realize that we run in Daemon mode, but we have other situations where
programs that create the config files can overlap and we merely using a lock
file and process check..  if either or both exist, it won't run for that
iteration..

---------------------------
Jason H. Frisvold
Head ATM Engineer
Engineering Dept.
Penteledata
friz at corp.ptd.net
---------------------------
"Only two things are infinite, the universe and human stupidity, and I'm not
sure about the former." - Albert Einstein


-----Original Message-----
From: Calvert, Neil [mailto:ncalvert at cabletron.com]
Sent: Tuesday, May 30, 2000 10:13 AM
To: mrtglist (E-mail)
Subject: [mrtg] enhancement suggestion


Hi folks,

I've been using MRTG in a remote environment (lots of frame relay, VPNs) and
its' been working very well. However, there is one set of circumstances
where it can possibly kill a box running it.

The problem materialises when for example you are polling say 100 devices
over a WAN link. If that WAN link goes down, you lose contact to all 100
devices. MRTG then does a poll, fail, retry loop for however many retries
and timeouts you have configured in SNMP_Session.pm.

If you have relatively large config files and large timeouts (as I do,
because of rather slow links) then what can happen is MRTG does not finish
its first run before starting on the second. The number of MRTG processes in
play continue to snowball until so much is being taken from the processor
that the box drops to its knees, and the only way to recover is to reboot or
kill all MRTG processes and disable the cron.

Now I have to say I'm not using RunAsDaemon mode because I like to have
direct control over MRTG and not have it sleep. This problem may not
manifest itself if you use RunAsDaemon mode. However...

I think a nice function of MRTG would be to do a quick 'are you up' check on
a polled device prior to sending snmp, say a 5 ping sequence (or however
many you want to send, user modifiable). If none of the pings come back then
assume the device is down for the duration of this poll and move to the next
target in the config file.

What this would do in essense is disable MRTG if your link goes down, and
re-enable it once the link is back, transparently. I'm not a perl guru or
I'd attempt it and test it myself, but I thought I'd throw it out there for
people to discuss. 

Feasable idea? Bad idea? I'd like to hear some thoughts on this before I dig
into my 'Perl for Dummies' book...

cheers

Neil

--
Unsubscribe mailto:mrtg-request at list.ee.ethz.ch?subject=unsubscribe
Archive     http://www.ee.ethz.ch/~slist/mrtg
FAQ         http://faq.mrtg.org    Homepage     http://www.mrtg.org

--
Unsubscribe mailto:mrtg-request at list.ee.ethz.ch?subject=unsubscribe
Archive     http://www.ee.ethz.ch/~slist/mrtg
FAQ         http://faq.mrtg.org    Homepage     http://www.mrtg.org