[collectd] randomly getting dl_open_worker assertion

[Riches Jr, Robert M]

(First-time poster, relatively new to collectd.)

With collectd version 5.2.0 compiled from source on Ubuntu 12.04, attempts to use the exec plugin seem to randomly get an assertion failure from dl_open_worker.  After boiling down the test case to pretty much the minimum, here's the collectd command I run:

                /opt/sbin/collectd -f &

Here is the script pointed to by the exec plugin's config file (indentation added):

#!/bin/bash

/bin/echo hello world 1>&2

Here's what I expect to see, which sometimes I get (indentation added):

[2013-02-20 08:01:17] Initialization complete, entering read-loop.
[2013-02-20 08:01:17] unixsock plugin: bind failed: Address already in use
[2013-02-20 08:01:17] exec plugin: exec_read_one: error = hello world

Here's what I get at other times (indentation added):

[2013-02-20 08:01:31] Initialization complete, entering read-loop.
[2013-02-20 08:01:31] unixsock plugin: bind failed: Address already in use
[2013-02-20 08:01:31] exec plugin: exec_read_one: error = Inconsistency detected by ld.so: dl-open.c: 221: dl_open_worker: Assertion `_dl_debug_initialize (0, args->nsid)->r_state == RT_CONSISTENT' failed!

There doesn't seem to be any rhyme or reason as to whether I get the expected result or the assertion failure.  I've googled for answers until my keyboard is wearing out, but nothing has come up that shows promise of a solution.

Regarding the behavior when I run the real script that doesn't send anything to stderr, it sometimes works perfectly, sometimes has the assertion failure.  The script and the program(s) it calls work perfectly every time when run by themselves.  It's only when collectd's exec plugin calls something that I see the assertion failure.  In another experiment, I put an absolute path to a binary executable in the she-bang line to remove bash from the mix, and the random assertion failures still happened.

Any suggestions?

Thanks,

Robert Riches

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.verplant.org/pipermail/collectd/attachments/20130220/4d8565e6/attachment.html>