I'm using net-snmp-5.0.3 on Solaris 8 x86.
The following trap appears in my logs:
2002-09-27 19:15:05 192.168.6.6 [192.168.6.6]:
DISMAN-EVENT-MIB::sysUpTimeInstance = Timeticks:
(120015) 0:20:00.15
SNMPv2-MIB::snmpTrapOID.0 = OID:
DISMAN-EVENT-MIB::mteTriggerFired
DISMAN-EVENT-MIB::mteHotTrigger = STRING: dskTable
DISMAN-EVENT-MIB::mteHotTargetName = STRING:
DISMAN-EVENT-MIB::mteHotContextName = STRING:
DISMAN-EVENT-MIB::mteHotOID = OID:
UCD-SNMP-MIB::dskErrorFlag.2
DISMAN-EVENT-MIB::mteHotValue = INTEGER: 0
UCD-SNMP-MIB::dskPath.2 = STRING: /usr
UCD-SNMP-MIB::dskErrorMsg.2 = STRING:
which seems incorrect since the usr filesystem
hasn't exceeded its threshold. In fact mteHotValue
is reported as zero meaning that snmpd knows
dskErrorFlag.2 isn't set so it shouldn't have
generated the trap.
Logged In: NO
snmpd started generating spurious traps after adding:
agentSecName internal
defaultMonitors yes
to the config file. Setting a breakpoint on send_mte_trap
gives
the following traceback:
#0 send_mte_trap (item=0x820edb8, trap_oid=0x8128a00,
trap_oid_len=10,
name_oid=0x818bc20, name_oid_len=11, value=0x820f550,
objowner=0x820ea20 "", objname=0x820ea30 "",
reason=0x8104e11 "existence: absent") at
disman/mteTriggerTable.c:2858
#1 0x080a6acb in mte_run_trigger (clientreg=8,
clientarg=0x820edb8)
at disman/mteTriggerTable.c:3578
#2 0x080e6074 in run_alarms () at snmp_alarm.c:209
#3 0x08066edd in receive () at snmpd.c:1017
#4 0x08066794 in main (argc=6, argv=0x8047a2c) at
snmpd.c:798
Making the following change:
1) Don't bother having a simple monitor trigger on an
existence test.
fixes the spurious traps, though I didn't actually
spend a lot of time debugging the problem so it's entirely
possible the actual bug is elsewhere.
---------------8<-----------------8<-------------------8<----------------
*** agent/mibgroup/disman/mteTriggerTable.c.ORIGINAL Wed
Jul 17 16:07:37 2002---
agent/mibgroup/disman/mteTriggerTable.c Mon Sep 30
19:58:24 2002
*************** parse_simple_monitor(const char *token,
*** 377,382 ****
--- 377,383 ----
StorageNew->mteTriggerBooleanStartup =
MTETRIGGERBOOLEANSTARTUP_TRUE;
StorageNew->mteTriggerThresholdStartup =
MTETRIGGERTHRESHOLDSTARTUP_RISINGORFALLING;
+ StorageNew->mteTriggerExistenceTest[0] = 0;
StorageNew->mteTriggerExistenceStartup = strdup(" ");
StorageNew->mteTriggerExistenceStartup[0] =
MTETRIGGEREXISTENCESTARTUP_PRESENT;
Logged In: YES
user_id=76148
Thanks for the patch.
fixed in cvs for 5.2, 5.1.3 and 5.0.10.