[collectd] Processes plugin

[Mark Moseley]

On Thu, Jan 14, 2010 at 10:27 AM, Florian Forster <octo at verplant.org> wrote:
> Hi Mark,
>
> On Thu, Jan 14, 2010 at 10:41:10AM +0100, Florian Forster wrote:
>> Yeah, sounds like an unsigned 32bit integer being cast to a signed one.
>
> turns out the data was first stored in a long (32bit / 64bit, depending
> on architecture), then a counter_t (unsigned 64bit) then cast to a
> derive_t (signed 64bit).
>
> I've changed this to use `derive_t' thorough the entire plugin. Not sure
> if this fixes the problem's core, though: It seems like you're
> missing all negative "counter" values. [*]
>
> After taking a good look at the RRDtool sources it turns out that there
> have been a number of incarnations of this bug over the year. The
> symptoms change over the time, and one of those is that values with
> leading hyphens are dismissed as incorrect. I've sent a patch fixing all
> the problems I could think of to the RRDtool mailing list and it's been
> applied already. [0]
>
> Regards,
> -octo
>
> [*] Though you'll need to write 2^63-1 bytes (roughly 9.2 Exabytes) for
>    this, assuming Linux provides 64bit counters.
> [0] <http://oss.oetiker.ch/rrdtool-trac/changeset/2001/trunk/program/src>


Wow, that was quick sleuthing! Sounds excellent, thanks for taking
care of it so quickly. Is there anything you'd like me to test for the
counter->derive_t change?

To answer your question in the previous email about librrd version,
the box I originally compiled on got accidentally upgraded (no joke)
from Etch to Lenny so I don't have the exact version from
compile-time, but the library being pulled in at runtime is
librrd_th.so.2.0.8, which is the lib from Etch's librrd2 package.
That's quite likely the exact version it was compiled against, since I
don't see a newer version in etch-backports.