the system.
Together with lm75(4) this module allows easy temperature monitoring over
SNMP, specially for embedded systems.
Manual page reviewed by: brueffer (D128)
bsnmp modules are located.
Section 3 (Library Functions) looks wrong for this manual page, which
contains only module description, that is why initially it was located
to section 8 (System Manager's Manual). On the other hand manual
pages for all other bsnmpd modules are already located in the section
3, and having all pages in one section looks more consistent. Also,
currently, similarly to manuals for other modules, snmp_hast manual
contains LIBRARY section, which is not good style for section 8.
Requested by: joel
X-MFC with: r250379
This compiler flag enforces that that people either mark variables
static or use an external declarations for the variable, similar to how
-Wmissing-prototypes works for functions.
Due to the fact that Yacc/Lex generate code that cannot trivially be
changed to not warn because of this (lots of yy* variables), add a
NO_WMISSING_VARIABLE_DECLARATIONS that can be used to turn off this
specific compiler warning.
Announced on: toolchain@
size and usage in hrStorageAllocationUnits. If the file system has
more than 2^31 allocations it can not be shown correctly and the
meters are useless.
In such cases follow net-snmp behaviour and increase
hrStorageAllocationUnits so the values fit under INT_MAX.
PR: bin/177183
Submitted by: Eugene Grosbein egrosbein rdtc.ru
MFC after: 2 weeks
indexing. When a device has gone it is not removed from device_map
table but just its entry_p field is set to NULL.
So when traversing device_map in disk_OS_get_ATA_disks() and
disk_OS_get_MD_disks() check for entry_p being NULL, otherwise the
bsnmpd crash is possible when a removed map entry is dereferenced.
Before the fix, for disk_OS_get_ATA_disks() the crash could be easily
reproduced running:
atacontrol detach ata1
The crash was not observed in disk_OS_get_MD_disks() because currently
snmp_hostres does no see md(4) disks: to get the device list it uses
devinfo(3), which does not return md devices.
Reported by: Miroslav Lachman 000.fbsd quip.cz
MFC after: 1 week
The reasoning behind this, is that if we are consistent in our
documentation about the uint*_t stuff, people will be less tempted to
write new code that uses the non-standard types.
I am not going to bump the man page dates, as these changes can be
considered style nits. The meaning of the man pages is unaffected.
MFC after: 1 month
It's too late to change this in 9.0 -- so we have a release with the
misspelling in the wild and should not break users that depend on it.
Deprecating/replacing it because of a one-char typo seems excessive.
In this contest, index refers to the index(3) function. In this case it
doesn't really harm, as this function is never called with idx == NULL.
MFC after: 2 weeks
last byte of the buffer.
Since we call refresh_device_tbl() for any devctl event types - no need
to check the first byte of buffer. Remove these checks.
Also remove logging for the case of unknown devd message. It incorrectly
triggers when all devctl events are not fit into one buffer and part of
unread data will be read in the next pass.
When length of data readed from devctl is equal to sizeof(buf), then try
to read from socket again, to read full data.
MFC after: 2 weeks
Sponsored by: The FreeBSD Foundation (the SNMPv3 bits), Google Summer of Code 2005
Reviewed by: philip@ (mostly), bz@ (earlier version based on p4 ch124545)
Approved by: philip@
- Sample CPU usage data from kern.cp_times, this makes for a far more
accurate and scheduler independent algorithm.
- Rip out the process list scraping that is no longer required.
- Don't update CPU usage sampling on every request, but every 15s
instead. This makes it impossible for an attacker to hide the CPU load
by triggering 4 samplings in short succession when the system is idle.
- After reaching the steady-state, the system will always report the
average CPU load of the last 60 sampled seconds.
- Untangling of call graph.
PR: kern/130222
Tested by: Julian Dunn <jdunn@aquezada.com>
Gustau Pérez <gperez@entel.upc.edu>
Jürgen Weiß <weiss@uni-mainz.de>
MFC after: 2 weeks
I'm unsure if some MIB standard states this must be the load average
for, eg. 300s, it looks like net-snmp isn't even bothering to implement
the CPU load reporting at all.
