[erlang-bugs] OTP-OS-MON-MIB bugs

Björn-Egil Dahlberg <>
Mon Jun 2 11:39:41 CEST 2008


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
> 
> http://www.erlang.org/mailman/listinfo/erlang-bugs




More information about the erlang-bugs mailing list