Ticket #74 (closed defect: fixed)

Opened 2 years ago

Last modified 14 months ago

Cache file creation issue causes failures later

Reported by: human Owned by: somebody
Version: 2.x Keywords: cache failure
Cc:

Description

I have a problem with MRTG 2.16.2 I have a router, cisco5, that sometimes fails to respond to SNMP. When that happens, MRTG fails to create the entry in the cache file (mrtg.ok.) This causes all attempts to get stats from that router to fail until I remove the cache file. It's failing because it can't find the entry in the cache file.

MRTG is running on Tru64 Unix with Perl 5.8.8

Here is the log from the initial failure. I think the key is the failure to write the key that causes this failure:

Use of uninitialized value in concatenation (.) or string at /usr/local/mrtg-2/bin/../lib/mrtg2/MRTG_lib.pm line 1596.

The key should exist despite the failure to get a response from SNMP earlier.

How do I fix this?

SNMP Error: no response received SNMPv1_Session (remote host: "cisco5.mumble.com" [1.2.3.4].161)

community: "public"

request ID: 2044679664

PDU bufsize: 8000 bytes

timeout: 2s retries: 5 backoff: 1)

at /usr/local/mrtg-2/bin/../lib/mrtg2/SNMP_util.pm line 492

SNMPGET Problem for ipAdEntIfIndex.192.168.45.5 ifInOctets.1 ipAdEntIfIndex.192.168.45.5 ifOutOctets.1 sysUptime sysName on public@…::::::v4only

at /usr/local/mrtg-2/bin/mrtg line 2203

SNMP Error: no response received SNMPv1_Session (remote host: "cisco5.mumble.com" [1.2.3.4].161)

community: "public"

request ID: 2044679684

PDU bufsize: 8000 bytes

timeout: 2s retries: 5 backoff: 1)

at /usr/local/mrtg-2/bin/../lib/mrtg2/SNMP_util.pm line 492

SNMPGET Problem for ipAdEntIfIndex.192.168.45.5 ifInOctets.1 ipAdEntIfIndex.192.168.45.5 ifOutOctets.1 sysUptime sysName on public@…::::::v4only

at /usr/local/mrtg-2/bin/mrtg line 2203

2009-09-30 22:20:01: WARNING: could not match&get cisco5.mumble.com:/ifInOctets for IP 192.168.45.5 SNMP Error: no response received SNMPv1_Session (remote host: "cisco5.mumble.com" [1.2.3.4].161)

community: "public"

request ID: 2044679685

PDU bufsize: 8000 bytes

timeout: 2s retries: 5 backoff: 1)

at /usr/local/mrtg-2/bin/../lib/mrtg2/SNMP_util.pm line 492

SNMPGET Problem for ipAdEntIfIndex.192.168.45.2 ifInOctets.2 ipAdEntIfIndex.192.168.45.2 ifOutOctets.2 sysUptime sysName on public@…::::::v4only

at /usr/local/mrtg-2/bin/mrtg line 2203

2009-09-30 22:20:01: WARNING: Could not match host:'public@cisco5.mumble.com:' ref:'Ip' key:'192.168.45.2' Use of uninitialized value in concatenation (.) or string at /usr/local/mrtg-2/bin/../lib/mrtg2/MRTG_lib.pm line 1596. 2009-09-30 22:20:31: ERROR: Target[cisco5.mumble.com_192.168.45.5][_IN_] ' $target->[0]{$mode} ' did not eval into defined data 2009-09-30 22:20:31: ERROR: Target[cisco5.mumble.com_192.168.45.5][_OUT_] ' $target->[0]{$mode} ' did not eval into defined data 2009-09-30 22:20:31: ERROR: Target[cisco5.mumble.com_192.168.45.2][_IN_] ' $target->[1]{$mode} ' did not eval into defined data 2009-09-30 22:20:31: ERROR: Target[cisco5.mumble.com_192.168.45.2][_OUT_] ' $target->[1]{$mode} ' did not eval into defined data

Change History

comment:1 Changed 21 months ago by human

I've the same problem in mrtg-2.16.2-3 but not in mrtg-2.14.7.

When there is a timeout the ifIndex is not written in the cache file, like

<comunity>@<host>  Ip      <ip> <ifIndex>
to
<comunity>@<host>  Ip      <ip>

After 5 minutes mrtg is expected to populate the missing ifIndex in the cache file, but it doesn't happen.

I think there is a bug using the function populateconfcache that populate the cache file

Reading the code i found the difference

# mrtg-2.14.7

if not defined readfromcache (that means something is missing in the cache file)

-> populateconfcache

# mrtg-2.16.2-3

if not populated host name AND not defined readfromcache

-> populateconfcache

But there is a case like populated host name => true defined readfromcache => false

that is not processed.

comment:2 Changed 14 months ago by oetiker

  • Status changed from new to closed
  • Resolution set to fixed

thanks ... fix for this is in r321

Note: See TracTickets for help on using tickets.
 

NOTE: The content of this website is accessible with any browser. The graphical design though relies completely on CSS2 styles. If you see this text, this means that your browser does not support CSS2. Consider upgrading to a standard conformant browser like Mozilla Firefox or Opera but also Apple's Safari or KDE's Konqueror for example.