Bug 562376
| Summary: | snmpd logs error messages | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 5 | Reporter: | Bryan Mason <bmason> | ||||
| Component: | net-snmp | Assignee: | Jan Safranek <jsafrane> | ||||
| Status: | CLOSED ERRATA | QA Contact: | BaseOS QE Security Team <qe-baseos-security> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | medium | ||||||
| Version: | 5.4 | CC: | bkurt, james.leddy, jwest, ksrot, ndevos, rvokal, tumeya | ||||
| Target Milestone: | rc | ||||||
| Target Release: | --- | ||||||
| Hardware: | All | ||||||
| OS: | Linux | ||||||
| Whiteboard: | |||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2011-07-21 09:09:57 UTC | Type: | --- | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 590060 | ||||||
| Attachments: |
|
||||||
Created attachment 389265 [details]
Proposed patch
This patch has been proposed by a customer.
I've tried to reproduce the issue with fake /proc and stats, but I have failed miserably... Could you please post content of /proc/net/dev/snmp, /proc/net/dev/snmp6 and /proc/net/dev_snmp6/* at the time the error occurs? The best would be strace -ttt -s 9999 of snmpd when the error is printed + few minutes before and after the error - I can see there what actually snmpd reads from /proc there. It seems it's quite hard to fulfill all the conditions to get to the "looks like a 64bit wrap, but prev!=new" error :(. Your patch won't probably work on 32bit Solaris, which provides OutTransmit statistics, so more clever approach is needed here - and I'd appreciate reproducer for that. Please note, I first found this BZ as it describes the exact same error message I see. But it was diagnosed to be a problem in the bnx2 driver which is actually Bug 542826. Maybe some others noticed the same or similar, possibly with other drivers? This is just a heads up that these messages might be caused by broken drivers, as discussed in Bug 539443 :) I understand that checking HCOutTransmits for 32bit overflow does not make much sense, since it is computed. I've fixed it differently upstream SVN rev. 19908 (just don't check the calculated counters at all) and I'll port it back to RHEL5. Still, I'd like to have a reproducer. An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2011-1076.html An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2011-1076.html This comment was flagged as spam, view the edit history to see the original text if required. |
Description of problem: snmpd unnecessarily generates the following error message: looks like a 64bit wrap, but prev!=new This error message ends up being unnecessary because it's being generated for a value that is calculated from other values, and thus has no previous value. Version-Release number of selected component (if applicable): net-snmp-5.3.2.2-7.el5_4.2 How reproducible: Unknown Steps to Reproduce: Unknown Actual results: Error message Expected results: No error message. Additional info: The error message is generated in the following bit of code in netsnmp_c64_check32_and_update() in snmplib/int64.c: 423 /* 424 * if we really have 64 bit counters, the summing we've been 425 * doing for prev values should be equal to the new values. 426 */ 427 if ((prev_val->low != new_val->low) || 428 (prev_val->high != new_val->high)) { 429 snmp_log(LOG_ERR, "looks like a 64bit wrap, but prev!=new\n" 429 ); 430 return -2; 431 } netsnmp_c64_check32_and_update() is, in turn called by netsnmp_access_systemstats_entry_update_stats() in agent/mibgroup/ip-mib/data_access/systemstats_common.c: 330 /* 331 * update 64bit counters 332 */ [..] 385 netsnmp_c64_check32_and_update(&prev_vals->stats.HCOutTransmits, 386 &new_vals->stats.HCOutTransmits, 387 &prev_vals->old_stats->HCOutTrans 387 mits, but HCOutTransmits is calculated in _calculate_entries() in agent/mibgroup/ip-mib/data_access/systemstats_common.c: 253 /* 254 * HCOutTransmits = HCOutRequests + HCOutForwDatagrams + HCOutFragC 254 reates 255 * - HCOutFragReqds - HCOutNoRoutes - HCOutDiscard 255 s 256 */ 257 if (!entry->stats.columnAvail[IPSYSTEMSTATSTABLE_HCOUTTRANSMITS] 258 && entry->stats.columnAvail[IPSYSTEMSTATSTABLE_HCOUTREQUESTS] 259 && entry->stats.columnAvail[IPSYSTEMSTATSTABLE_HCOUTFORWDATAGRAM 259 S] 260 && entry->stats.columnAvail[IPSYSTEMSTATSTABLE_HCOUTFRAGREQDS 260 ] 261 && entry->stats.columnAvail[IPSYSTEMSTATSTABLE_HCOUTNOROUTES] 262 && entry->stats.columnAvail[IPSYSTEMSTATSTABLE_HCOUTFRAGCREAT 262 ES] 263 && entry->stats.columnAvail[IPSYSTEMSTATSTABLE_HCOUTDISCARDS]) { 264 265 U64 tmp, tmp2, tmp3; 266 tmp = entry->stats.HCOutRequests; 267 u64Incr(&tmp, &entry->stats.HCOutForwDatagrams); 268 u64Incr(&tmp, &entry->stats.HCOutFragCreates); 269 270 u64Subtract(&tmp, &entry->stats.HCOutFragReqds, &tmp2); 271 u64Subtract(&tmp2, &entry->stats.HCOutNoRoutes, &tmp3); 272 u64Subtract(&tmp3, &entry->stats.HCOutDiscards, &entry->stats.HC 272 OutTransmits); Because HCOutTransmits is calculated from other values, it's new_vals are always 0, and thus doesn't need a wrap check. When a wrap check is done, the error message above is needlessly generated.