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>