After some research, ECMA-262 15.12.3 says nan and infinite numbers
aren't representable in JSON and should be serialized as the string
null. I figure any strictly-compliant JSON parser will fail on parsing
JSON data containing nans as emitted by collectd's utils_format_json
routines.
This patch makes collectd's JSON output compliant in the case of
infinite or nan gauge values.
Pavel Piatruk [Fri, 22 Jan 2010 08:13:29 +0000 (09:13 +0100)]
contrib/collection.cgi: Added ability to hide specified types.
It is useful when you don't want to see many graphs. How to use the patch:
apply it to collection.cgi and add lines with keyword ,,dontshowtype'' to
/etc/collectd/collection.conf:
Ben Knight [Tue, 1 Dec 2009 08:03:27 +0000 (09:03 +0100)]
src/utils_cmd_listval.c: Free memory returned by `uc_get_names'.
We've run into a memory leak in collectd, triggered by usage of 'listval'
via the unixsock plugin.
When making a 'listval' call, utils_cmd_listval.c:handle_listval() calls
utils_cache.c:uc_get_names() to retrieve a list of active value names from the
internal cache. uc_get_names() uses realloc() to allocate memory in which to
store the list, and returns pointers.
handle_listval() does not perform a free() on the returned memory. Each time
listval is called, some memory is leaked. handle_getval() does not suffer from
the same problem - a free() is called in that case.
Florian Forster [Mon, 9 Nov 2009 11:04:23 +0000 (12:04 +0100)]
snmp plugin: Fix handling of strings with control characters.
If a byte of a string has a value <32, the string is printed as a
hex-string. This fixes issues with some devices returning MAC addresses
as "strings".
Sebastian Harl [Wed, 28 Oct 2009 18:32:36 +0000 (19:32 +0100)]
src/Makefile: Support parallel builds when creating the manpages.
A temporary file name is used when creating the manpages. So far, a static
file name had been used for that, thus causing race conditions. Now, a unique
suffix (PID) is used to fix that.
unixsock plugin: Fix a (well hidden) race condition.
Within the client handling thread, fdopen is called twice on the file
descriptor passed to the thread. Later those file handles are closed like:
fclose (fhin);
fclose (fhout);
This is a race condition, because the first call to fclose will close the file
descriptor. The second call to fclose will try the same. Usually, it would fail
silently and all is well. On a busy machine, however, another thread may just
have opened a file or accepted a socket. In that case an arbitrary file
descriptor is closed. If the file descriptor is opened yet again fast enough,
data may even end up in a totally wrong location.
As a work-around the file descriptor is not dup'ed so each fdopen operates on
its own file descriptor. As an alternative the "r+" mode and a single file
handle may be suitable, too.
Many thanks to Sven Trenkel for pointing me into the right directioin :)
Thanks for the reply, but we detect a minor bug in the previous patch
due to kernel 2.4
The correct patch is attached. The bug is related with kernels 2.4,
where task/ directory do not exists and ps_read_task return -1, which is
catched and raise an error (breaking the ps_read_process function), so a
NaN is dispatched istead of values (number of process:1, number of
threads :1).
processes plugin: Remove unnecessary call of realloc(3).
Hi Florian (et al)
> you're right, the (re-)allocation of the memory can probably be avoided
> if the function is turned into one with the following prototype:
> -- 8< --
> static int *ps_read_tasks (int pid,
> unsigned long *ret_num_proc,
> unsigned long *ret_num_lwp);
> -- >8 --
Mmm, why not something like: "static int ps_read_task(pid)"?
This returns the number of task for pid passed as argument.
(AFAIK the function only return the number ot threads), why
we need the ret_num_proc and the ret_num_lwp parameters?
My proposal is attached (code is always cleaner than explanations :P)
Build system: Check for “libiptc/libip6tc.h” and “linux/netfilter/x_tables.h”, too.
Apparently “linux/netfilter/x_tables.h” is not available with older
kernels which leads to build fails there:
-- 8< --
In file included from libiptc.c:47,
from libip4tc.c:136:
xtables.h:24:38: linux/netfilter/x_tables.h: No such file or directory
-- >8 --
src/owniptc/Makefile.am: Don't search KERNEL_DIR for headers.
The iptc library is currenly only enabled, if the required headers where
found without “-I${KERNEL_DIR}”. Adding it to the CFLAGS when building
the shipped version of libiptc just breaks things, for example on
“collectd-master-amd64-linux-2.6”:
Linux hotdamn 2.6.9-42.ELsmp #1 SMP Tue Aug 15 10:35:26 BST 2006 x86_64 x86_64 x86_64 GNU/Linux
Only check for “iptc_handle_t” and “ip6tc_handle_t” if using a
system-wide version of libiptc. If we use the shipped version, we *know*
it provides these types.
Build system: Improve detection of the iptc library.
When checking for the iptc headers and data types, the configure script
added the kernel directory to the CFLAGS. Later, when actually building
the iptables plugin, the CFLAGS were left untouched.
At least on Debian, the “real” kernel headers are not required – the
libc versions in /usr/include/linux are sufficient. The usage of
KERNEL_DIR has therefore been removed from the iptc checks.
In addition, an directory specified by “--with-libiptc=/path” is no
longer added to the global CFLAGS but rather to the iptables specific
CPPFLAGS.
Hopefully this resolved build problems on various platforms.
projects / thirdparty / collectd.git / log
