Bug 1212151
| Summary: | collectd-java cannot find libjvm.so | ||
|---|---|---|---|
| Product: | [Fedora] Fedora EPEL | Reporter: | Andrei Nistor <coder.tux> |
| Component: | collectd | Assignee: | Ruben Kerkhof <ruben> |
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | epel7 | CC: | gregswift, jskarvad, kevin, mhlavink, ruben |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2015-04-16 13:05:06 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
Thanks for the report Andrei. This seems to be related to #449456 I have no idea how collectd is supposed to know the location of libjvm.so if it's not in the library search path, apart from hardcoding the path which doesn't seem like a good idea. Let me give this some thought. Think I found a better workaround that works around the java update issues. I've noticed that /usr/lib/jvm/jre is managed by alternatives, so here goes: # cat /etc/ld.so.conf.d/java.conf /usr/lib/jvm/jre/lib/amd64/server/ Collectd seems to be starting up fine now (although it's still not working as expected, it's probably a configuration issue) Nice workaround, something that should be done in openjdk package by default imho. I'm going to close this since there's not much that can be done from Collectd's point of view. |
Description of problem: The collectd-java plugins links against libjvm.so, but as far as I can tell that .so is installed in a non-standard location by java-1.7.0-openjdk-headless: /usr/lib/jvm/java-1.7.0-openjdk-1.7.0.79-2.5.5.1.el7_1.x86_64/jre/lib/amd64/server/libjvm.so === /var/log/messages === Apr 15 12:09:03 cs1825 systemd: Starting Collectd statistics daemon... Apr 15 12:09:03 cs1825 systemd: Started Collectd statistics daemon. Apr 15 12:09:03 cs1825 collectd[15719]: lt_dlopen ("/usr/lib64/collectd/java.so") failed: file not found. The most common cause for this problem is missing dependencies. Use ldd(1) to check the dependencies of the plugin / shared object. Apr 15 12:09:03 cs1825 collectd[15719]: plugin_load: Load plugin "java" failed with status 1. Apr 15 12:09:03 cs1825 collectd[15719]: Initialization complete, entering read-loop. ====== === ldd output === # ldd /usr/lib64/collectd/java.so linux-vdso.so.1 => (0x00007fffc45c7000) libjvm.so => not found libdl.so.2 => /lib64/libdl.so.2 (0x00007f4c2f9fa000) libc.so.6 => /lib64/libc.so.6 (0x00007f4c2f639000) /lib64/ld-linux-x86-64.so.2 (0x00007f4c2fe13000) ====== Version-Release number of selected component (if applicable): collectd-5.4.2-1.el7.x86_64 collectd-java-5.4.2-1.el7.x86_64 collectd-generic-jmx-5.4.2-1.el7.x86_64 java-1.7.0-openjdk-1.7.0.79-2.5.5.1.el7_1.x86_64 java-1.7.0-openjdk-headless-1.7.0.79-2.5.5.1.el7_1.x86_64 How reproducible: Always. Steps to Reproduce: 1. install the packages mentioned above 2. add the following to /etc/collectd.d/java.conf <Plugin "java"> JVMArg "-verbose:jni" JVMArg "-Djava.class.path=/usr/share/collectd/java/collectd-api.jar:/usr/share/collectd/java/generic-jmx.jar" LoadPlugin "org.collectd.java.GenericJMX" </Plugin> 3. watch /var/log/messages Actual results: Collectd doesn't load the java plugin because libjvm.so is not in the library path. Expected results: Collectd should find libjvm.so Additional info: It's possible to work around this issue by mucking with the LD_LIBRARY_PATH, but this is very costly since we have to change it every time there's a java update.