[collectd] Collectd 3.4 not running after update from 3.3

[Florian Forster]

Hello Jan,

On Wed, Dec 07, 2005 at 12:08:02AM +0100, Jan Huijsmans wrote:
> Hmmm, I've bin able to update all systems to the new version, except
> one. The last has a small defect. After the update of serial-0 all
> updates halt. Is there a way to get some logging from collectd to
> check what's going wrong?                               

if the serial RRD gets updated, the problem is most likely _not_ in that
module. The modules are triggered in the reverse order in which they
were loaded (it's a linked list and modules are insert at the
beginning). On many systems this is the reverse alphabetical order, but
collectd doesn't sort anything so this is not neccessarily true. Your
best bet is to strace the daemon, see in which order the modules are
read. The problem is (most likely) in the module read just before the
`serial' module..

> Ok, it's not an error that started with installing the 3.4 version, as
> going back to 3.3 didn't help... Switching from the stable to the
> unstable source did... but I don't know what went wrong and what's
> different between the versions. I'm using sid and etch together as
> debian package supplier.

That's weird. Theres hardly any difference between the packages: I
unpack the source tarball, change the librrd-dependency to either
version 1.0 or 1.2 (for stable/sarge or unstable/sid) and build the
package.

As a sidenote: I've had that problem once and it turned out to be the
hddtemp module. It tried to connect to the hddtemp-port and waited for a
timeout. There is a logic in hddtemp (the module, not the actual
program) which lets the time between (failed) connections grow. It grows
exponentially to 86400 seconds (one day).

However, since this module and the ping module potentially wait long for
an answer I have been thinking about letting them run in a seperate
thread. I've been thinking about letting each process run in an own
thread, too. The reason I haven't done that yet is because I don't want
to pull in  a entire new class of portability issues.. Any thoughts on
that, anyone?

Regards,
-octo
-- 
Florian octo Forster
Hacker in training
GnuPG: 0x91523C3D
http://verplant.org/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mailman.verplant.org/pipermail/collectd/attachments/20051207/2682a070/attachment.pgp