[erlang-bugs] OTP-OS-MON-MIB bugs
Edwin Fine
erlang-questions_efine@REDACTED
Thu Aug 21 06:35:21 CEST 2008
Björn-Egil,
I reported this bug for R12B-2, and only just got back to working with SNMP.
I see that this bug is still present in R12B-3. I'm not surprised, seeing
that R12B-3 was released on June 11 and I only reported the issue on May 28.
That's not nearly enough time to fix and test it.
Will it be fixed for the next release?
Regards,
Edwin Fine
On Mon, Jun 2, 2008 at 5:39 AM, Björn-Egil Dahlberg
<egil@REDACTED>wrote:
> Thank you for pointing out this problem.
>
> I will look into it.
>
> Regards,
> Björn-Egil
> Erlang/OTP
>
> Edwin Fine wrote:
>
>> I need to thank Martin Bjorkland for helping me recognize this bug.
>>
>> 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).
>>
>> *The More Serious One*
>>
>> 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:
>>
>> loadSystemTotalMemory Gauge32,
>> loadSystemUsedMemory Gauge32,
>> loadLargestErlProcessUsedMemory Gauge32,
>>
>> 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.
>>
>> *Example of error:*
>>
>> $ snmpwalk -m ALL -u initial 127.0.0.1:4000 <http://127.0.0.1:4000>
>> loadSystemTotalMemory.0
>> Error in packet.
>> Reason: (genError) A general failure occured
>> Failed object: OTP-OS-MON-MIB::loadSystemTotalMemory.""
>>
>> OTP-OS-MON-MIB::loadSystemTotalMemory."" = No Such Instance currently
>> exists at this OID
>>
>> -------------
>> *Agent error message*
>>
>> I believe the agent error message below shows that the value of 8386678784
>> (not coincidentally, about 8 GB) is out of range.
>>
>> =ERROR REPORT==== 28-May-2008::00:26:03 ===
>> ** User error: Got 8386678784 from {os_mon_mib,load_table,[]}. Using
>> wrongValue
>>
>> --------------
>> *Proposed Solution*
>>
>> The solution according to Martin is to change the Gauge32 types to be
>> CounterBasedGauge64, from HCNUM-TC.
>>
>> I tried this in OTP-OS-MON-MIB as follows:
>>
>> 1. cd /usr/local/lib/erlang/lib/os_mon-2.1.5/mibs
>> 2. cp OTP-OS-MON-MIB.mib OTP-OS-MON-MIB.mib.buggy
>> 3. (Modified OTP-OS-MON-MIB.mib as shown in the diff output at the
>> end of this email.)
>> 4. cp /usr/share/snmp/mibs/HCNUM-TC.txt ./HCNUM-TC.mib
>> 5. erlc -o ../priv/mibs/ -I ../priv/mibs -I
>> ../../otp_mibs-1.0.4.1/priv/mibs HCNUM-TC.mib OTP-OS-MON-MIB.mib
>> 6. Reloaded the agent
>>
>>
>> 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.
>>
>> *** [2008:05:28 22:07:30 4113] SNMP MASTER-AGENT LOG ***
>> apply: os_mon_mib,disk_table,[get_next,[],[0]]
>>
>> *** [2008:05:28 22:07:30 4113] SNMP MASTER-AGENT INFO ***
>> Call to:
>> Module: os_mon_mib
>> Function: disk_table
>> Args: [get_next,[],[0]]
>>
>> resulted in an 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}]}
>>
>> =ERROR REPORT==== 28-May-2008::18:07:30 ===
>> ** 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)
>> --------------------------------------
>> ----------------------
>> $ diff -U 0 OTP-OS-MON-MIB.mib.buggy OTP-OS-MON-MIB.mib
>> --- OTP-OS-MON-MIB.mib.buggy 2008-05-06 10:02:27.000000000 -0400
>> +++ OTP-OS-MON-MIB.mib 2008-05-28 17:28:42.000000000 -0400
>> @@ -14,0 +15,2 @@
>> + CounterBasedGauge64
>> + FROM HCNUM-TC
>> @@ -111,2 +113,2 @@
>> - loadSystemTotalMemory Gauge32,
>> - loadSystemUsedMemory Gauge32,
>> + loadSystemTotalMemory CounterBasedGauge64,
>> + loadSystemUsedMemory CounterBasedGauge64,
>> @@ -114 +116 @@
>> - loadLargestErlProcessUsedMemory Gauge32,
>> + loadLargestErlProcessUsedMemory CounterBasedGauge64,
>> @@ -129 +131 @@
>> - SYNTAX Gauge32
>> + SYNTAX CounterBasedGauge64
>> @@ -138 +140 @@
>> - SYNTAX Gauge32
>> + SYNTAX CounterBasedGauge64
>> @@ -156 +158 @@
>> - SYNTAX Gauge32
>> + SYNTAX CounterBasedGauge64
>> @@ -283,4 +285,4 @@
>> - GROUP loadAlarmsGroup
>> - DESCRIPTION
>> - "This group is optional for systems implementing the
>> - load supervison functionality."
>> + --GROUP loadAlarmsGroup
>> + --DESCRIPTION
>> + -- "This group is optional for systems implementing the
>> + -- load supervison functionality."
>> @@ -291,4 +293,4 @@
>> - GROUP diskAlarmsGroup
>> - DESCRIPTION
>> - "This group is optional for systems implementing the
>> - disk supervison functionality."
>> + --GROUP diskAlarmsGroup
>> + --DESCRIPTION
>> + -- "This group is optional for systems implementing the
>> + -- disk supervison functionality."
>>
>> --------------------------------------------
>> *The less serious bug
>>
>> *Maybe this is not a bug, but two groups are referenced that do not exist
>> in OTP-OS-MON-MIB.mib:
>>
>> GROUP loadAlarmsGroup
>> GROUP diskAlarmsGroup
>>
>> This causes snmpwalk to emit error messages. Commenting out the above
>> lines seemed to have no effect other than stopping the snmpwalk error
>> messages.
>>
>> Regards,
>> Edwin Fine
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> erlang-bugs mailing list
>> erlang-bugs@REDACTED
>> http://www.erlang.org/mailman/listinfo/erlang-bugs
>>
>
>
>
--
For every expert there is an equal and opposite expert - Arthur C. Clarke
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-bugs/attachments/20080821/57e82bba/attachment.htm>
More information about the erlang-bugs
mailing list