[collectd] [Bug 568234] [NEW] java plugin does not work with non-openjdk java

Gabe Nell gabe.nell at gmail.com
Fri Apr 23 08:04:18 CEST 2010


Thanks Sebastian. The work-around suggestion to use LD_PRELOAD or
LD_LIBRARY_PATH pointing to the Sun Java version worked.

I agree that the best solution would be for the collectd java plugin to do
its own search for the Java library rather than relying on the location it
was built with. I wasn't sure if there was something that could be done at
the Ubuntu level, like building it with

configure --with-java=<path to some location that will resolve to both sun
or openjdk via symlink>

I'm not familiar enough with Ubuntu to know whether that is a possibility,
as it would very likely be lower cost.

Gabe

Hi,
>
> On Thu, Apr 22, 2010 at 04:14:19AM -0000, Gabriel Nell wrote:
> > I'm on lucid, and I've installed collectd-core and sun-java6-jdk from
> > the partners repository. Updating collectd.conf to have "LoadPlugin
> > java" results in the following failure:
> >
> > lt_dlopen (/usr/lib/collectd/java.so) failed: file not found
> > Unable to load plugin java.
> >
> > The file referenced does in fact exist. I think what's going on is that
> > java.so was built statically linking to the openjdk location of
> > libjvm.so. Installing openjdk-6-jdk resolved the issue.
>
> Mostly right (it's not statically linked but it includes a static search
> path compiled in, i.e. an rpath). The problem is that libjvm.so (no
> matter which Java is used) can not be found in the search path of the
> dynamic loader. So, there needs to be some way to tell the loader where
> to find libjvm.so and this is currently done by specifying an rpath.
>
> I can think of the following alternate way to handle this (and, afaik,
> this is the most common approach used in that case): let the "java"
> plugin search for libjvm.so itself and load it using dlopen(). The
> search path could then include a built-in default, a configurable path
> and $JAVA_HOME (in order of increasing priority). Patches would be very
> welcome! :-)
>
> As a work-around for now, you should be able to run collectd as
> `LD_PRELOAD=/path/to/whatever/libjvm.so collectd'. The loader then won't
> try to load libjvm.so again. Also, specifying an appropriate
> LD_LIBRARY_PATH should do the trick. The former could be used to
> explicitly specify which Java should be used.
>
> > The bug here is that the collectd-core package has a hidden dependancy
> > on a specific flavor of java. I suspect this repros on pre-lucid as
> > well.
>
> This has always been the case since the introduction of the "java"
> plugin in collectd 4.7.0.
>
> > --
> > java plugin does not work with non-openjdk java
> > https://bugs.launchpad.net/bugs/568234
> > you received this bug notification because you are subscribed to
> > collectd in ubuntu.
>
> (JFTR)
>
> Cheers,
> Sebastian
>
> --
> Sebastian "tokkee" Harl +++ GnuPG-ID: 0x8501C7FC +++ http://tokkee.org/
>
> Those who would give up Essential Liberty to purchase a little Temporary
> Safety, deserve neither Liberty nor Safety.         -- Benjamin Franklin
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.9 (GNU/Linux)
>
> iEYEARECAAYFAkvQJQcACgkQEFEKc4UBx/wUPQCfc쭊㽴솦鸻£盥䲢�
> J5AAn1GaX1GoRqyBWLfMYA8FpzYR/CUx
> =9VmH
> -----END PGP SIGNATURE-----
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.verplant.org/pipermail/collectd/attachments/20100422/3543c075/attachment.htm 


More information about the collectd mailing list