On 31 March 2010 03:25, Wes Hardaker <[email protected]> wrote: > Wayyyy behind the times on this (sorry), but just FYI in case you > haven't dealt with them already.
I've applied two-and-a-bit of the proposed patches. It's really only the latching of disk stats that is outstanding. > DS> 1) Latch disk statistics: no / 54x only / both 54x and 52x The second version of the patch performs the latching checks on the raw stats as read from the system - i.e. before applying the scaling multiplier (which is where any number wrapping is likely to arise). So I'm not sure that this is still a factor. I agree that number wrapping sucks - but that's the whole point of this patch. Currently the disk statistics *do* wrap - this patch is intended to prevent that behaviour. > After reading the discussions, -1 unless all the issues are resolved. > I do think the problem needs to be fixed, but it needs to be fixed > without introducing new bugs. I'm not clear which version of the patch you've been looking at. But I believe the second version *does* address the issues that have been raised. > DS> 4) MIB dir path logging: no / 54x only / both 54x and 52x > > -1 for both. I agree it's useful, but it doesn't seem right for a bug > branch and I'm not sure given time and discussion it would be the > solution we'd pick (it might be; I'm just not sure). I'm not particularly bothered about the 5.2.x line, since this is being shut down anyway, and we'd want to discourage people from using it. But I'm strongly in favour of including some form of this fix in the 5.4.x branch. Yes - it's not strictly a bug, but it would significantly aid with the task of supporting the software. Problems with finding config or MIB files are extremely common - particularly when switching from vendor-supplied to user-compiled agents (or vice versa). But confirming that this is indeed the issue currently involves getting the user to restart the agent with suitable debug flags enabled, and wading through the output. I've already applied a patch to includ the relevant search path in these two error messages (for the 5.4.x line only). This seems such a simple addition, and would make a noticeable difference in responding to such email queries. I've omitted the code to include this information in the usage output (though I think it would be useful there as well), so it's only triggered by the actual errors. I suppose I could revert this change, but I'm loth to drop this altogether,. Unless you're volunteering to take over as point man for email support? Dave ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Net-snmp-coders mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
