I need to thank Martin Bjorkland for helping me recognize this bug.<br><br>I believe that the file OTP-OS-MON-MIB.mib has two sets of bugs, one more serious than the other. Fixing the first bug also showed up a potential third bug (see later).<br>
<br><b>The More Serious One</b><br><br>The following objects in OTP-OS-MON-MIB.mib are defined as type Gauge32, and cause problems when the values returned are actually greater than a 32-bit value can represent:<br><br> loadSystemTotalMemory Gauge32,<br>
loadSystemUsedMemory Gauge32,<br> loadLargestErlProcessUsedMemory Gauge32,<br><br>To reproduce this problem, simply do an snmpwalk on a 64-bit system that has more than 4 GB of memory (mine is Ubuntu 7.10 x86_64 with 8 GB) and try to get the loadSystemTotalMemory.0 object.<br>
<br><b>Example of error:</b><br><br>$ snmpwalk -m ALL -u initial <a href="http://127.0.0.1:4000">127.0.0.1:4000</a> loadSystemTotalMemory.0<br>Error in packet.<br>Reason: (genError) A general failure occured<br>Failed object: OTP-OS-MON-MIB::loadSystemTotalMemory.""<br>
<br>OTP-OS-MON-MIB::loadSystemTotalMemory."" = No Such Instance currently exists at this OID<br><br>-------------<br><b>Agent error message</b><br><br>I believe the agent error message below shows that the value of 8386678784 (not coincidentally, about 8 GB) is out of range.<br>
<br>=ERROR REPORT==== 28-May-2008::00:26:03 ===<br>** User error: Got 8386678784 from {os_mon_mib,load_table,[]}. Using wrongValue<br><br>--------------<br><b>Proposed Solution</b><br><br>The solution according to Martin is to change the Gauge32 types to be CounterBasedGauge64, from HCNUM-TC.<br>
<br>I tried this in OTP-OS-MON-MIB as follows:<br><ol><li>cd /usr/local/lib/erlang/lib/os_mon-2.1.5/mibs</li><li>cp OTP-OS-MON-MIB.mib OTP-OS-MON-MIB.mib.buggy</li><li>(Modified OTP-OS-MON-MIB.mib as shown in the diff output at the end of this email.)</li>
<li>cp /usr/share/snmp/mibs/HCNUM-TC.txt ./HCNUM-TC.mib</li><li>erlc -o ../priv/mibs/ -I ../priv/mibs -I ../../otp_mibs-1.0.4.1/priv/mibs HCNUM-TC.mib OTP-OS-MON-MIB.mib</li><li>Reloaded the agent<br></li></ol>This fixed the error, but exposed another possible bug. If otp-mib is not loaded into the agent, then the snmpwalk causes this error below. This is reproducible. I would think that if otp-mib was absent, the agent would at least show that a required dependency was not loaded and not crash.<br>
<br>*** [2008:05:28 22:07:30 4113] SNMP MASTER-AGENT LOG *** <br> <br> apply: os_mon_mib,disk_table,[get_next,[],[0]]<br><br>*** [2008:05:28 22:07:30 4113] SNMP MASTER-AGENT INFO *** <br> Call to: <br> Module: os_mon_mib<br>
Function: disk_table<br> Args: [get_next,[],[0]]<br><br>resulted in an exit<br><br> {{badmatch,false},<br> [{snmp_generic,table_info,1},<br> {snmp_generic_mnesia,table_func,4},<br> {os_mon_mib,update_disk_table,0},<br>
{snmp_shadow_table,update,3},<br> {snmp_shadow_table,table_func,4},<br> {snmpa_agent,dbg_apply,3},<br> {snmpa_agent,get_next_values_all_rows,6},<br> {snmpa_agent,get_next_table,4}]}<br><br>=ERROR REPORT==== 28-May-2008::18:07:30 ===<br>
** User error: Invalid return value {'EXIT',{{badmatch,false},[{snmp_generic,table_info,1},{snmp_generic_mnesia,table_func,4},{os_mon_mib,update_disk_table,0},{snmp_shadow_table,update,3},{snmp_shadow_table,table_func,4},{snmpa_agent,dbg_apply,3},{snmpa_agent,get_next_values_all_rows,6},{snmpa_agent,get_next_table,4}]}} from {os_mon_mib,disk_table,[]} (get_next)<br>
--------------------------------------<br>----------------------<br>$ diff -U 0 OTP-OS-MON-MIB.mib.buggy OTP-OS-MON-MIB.mib<br>--- OTP-OS-MON-MIB.mib.buggy 2008-05-06 10:02:27.000000000 -0400<br>+++ OTP-OS-MON-MIB.mib 2008-05-28 17:28:42.000000000 -0400<br>
@@ -14,0 +15,2 @@<br>+ CounterBasedGauge64<br>+ FROM HCNUM-TC<br>@@ -111,2 +113,2 @@<br>- loadSystemTotalMemory Gauge32,<br>- loadSystemUsedMemory Gauge32,<br>+ loadSystemTotalMemory CounterBasedGauge64,<br>
+ loadSystemUsedMemory CounterBasedGauge64,<br>@@ -114 +116 @@<br>- loadLargestErlProcessUsedMemory Gauge32,<br>+ loadLargestErlProcessUsedMemory CounterBasedGauge64,<br>@@ -129 +131 @@<br>- SYNTAX Gauge32<br>
+ SYNTAX CounterBasedGauge64<br>@@ -138 +140 @@<br>- SYNTAX Gauge32<br>+ SYNTAX CounterBasedGauge64<br>@@ -156 +158 @@<br>- SYNTAX Gauge32<br>+ SYNTAX CounterBasedGauge64<br>@@ -283,4 +285,4 @@<br>
- GROUP loadAlarmsGroup<br>- DESCRIPTION<br>- "This group is optional for systems implementing the<br>- load supervison functionality."<br>+ --GROUP loadAlarmsGroup<br>
+ --DESCRIPTION<br>+ -- "This group is optional for systems implementing the<br>+ -- load supervison functionality."<br>@@ -291,4 +293,4 @@<br>- GROUP diskAlarmsGroup<br>- DESCRIPTION<br>
- "This group is optional for systems implementing the<br>- disk supervison functionality."<br>+ --GROUP diskAlarmsGroup<br>+ --DESCRIPTION<br>+ -- "This group is optional for systems implementing the<br>
+ -- disk supervison functionality."<br><br>--------------------------------------------<br><b>The less serious bug<br><br></b>Maybe this is not a bug, but two groups are referenced that do not exist in OTP-OS-MON-MIB.mib:<br>
<br> GROUP loadAlarmsGroup<br> GROUP diskAlarmsGroup<br><br>This causes snmpwalk to emit error messages. Commenting out the above lines seemed to have no effect other than stopping the snmpwalk error messages.<br>
<br>Regards,<br>Edwin Fine<br>