Looks like the sigar logging places most things in the "Sigar" category, this does not look promising though.
It looks like they just swallow the exception in loadLibrary except for the message, which in this case is the not very helpful " /Applications/jopr/jopr-agent-2.1.0.GA/lib/libsigar-universal-macosx.dylib". I can't even tell from that which type of exception is the root cause, and sure enough I don't see a lot of additional info:
2009-02-18 13:23:40,534 DEBUG [main] (Sigar)- /Applications/jopr/jopr-agent-2.1.
at java.lang.Class.forName0(Native Method)
Looking through ArchLoader, I can't even find where an exception would be thrown that would include nothing but the library name
Of course, the repository head may have been changed already to address whatever this issue is. Any ideas?
You could also try setting the System property "sigar.nativeLogging" to "true", i.e. by passing -Dsigar.nativeLogging=true to the Agent JVM when starting it. This will cause the native side of Sigar to loag debug info. Note, setting the RHQ_AGENT_DEBUG environment variable to any value prior to starting the Agent should automatically add the -Dsigar.nativeLogging=true argument to the command line.
I'm pretty sure I set that automatically when you enable agent debug via the RHQ_AGENT_DEBUG env var.
But when you do that RHQ_AGENT_DEBUG thing, the rhq-agent script will switch to using the built-in log4j-debug.xml found in the agent jar file - so it will ignore your customized log4j.xml - you can easily use "debug -f log4j.xml" to switch back to your customized log config if you want.
Got it. It wasn't the additional Sigar debugging but the other stuff that came out that tipped me off. I noticed that the output from the Sigar jar file when executed on the command line claimed java 1.5 was in use while the agent is using 1.6 from the JAVA_HOME variable. I set JAVA_HOME to 1.5 and native initialized when the agent came back up. I don't know if this is a problem with running under 1.6 or a conflict between the java binary on my path and the one referenced in JAVA_HOME though.....
ugh - I wonder if SIGAR under the covers is somehow looking at JAVA_HOME?
We run the agent under 1.6 all the time - so just using 1.6 isn't a problem. Must be something else - perhaps something in SIGAR?
BTW: read the comments/settings in rhq-agent-env.sh to see the different settings you can set in the agent - a few are for telling the agent which Java to use. JAVA_HOME is just the last-resort fallback for the agent.
Have you run it under 1.6 on a mac? This is what happens when I attempt to launch the sigar jar explicitly with the 1.6 jvm
/System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home/bin/java -jar sigar-220.127.116.11.jar /Applications/jopr/jopr-agent-2.1.0.GA/lib/libsigar-universal-macosx.dylib: org.hyperic.sigar.SigarException: /Applications/jopr/jopr-agent-2.1.0.GA/lib/libsigar-universal-macosx.dylib: at org.hyperic.sigar.Sigar.loadLibrary(Sigar.java:160) at org.hyperic.sigar.Sigar.<clinit>(Sigar.java:90) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:169) at org.hyperic.sigar.SigarLoader.class$(SigarLoader.java:79) at org.hyperic.sigar.SigarLoader.getLocation(SigarLoader.java:79) at org.hyperic.sigar.cmd.Runner.main(Runner.java:161) Class Not Found: junit/framework/TestCase Unable to locate: junit.jar
hmmmmm.... looks familiar.....
Ha! Why is SIGAR trying to load JUnit??
Perhaps it is is because the 1.6 JVM is 64-bit. It looks like SIGAR didn't add support for 64-bit JVM on OSX until v1.6.2 (see http://forums.hyperic.com/jiveforums/thread.jspa?messageID=22675å¢“). If it's not 64-bit, then perhaps the version of SIGAR JON is using (1.5.0) doesn't even support 32-bit Java 1.6 on OSX.
garfunkel:lib dave$ /System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home/bin/java -version
java version "1.6.0_07"
Java(TM) SE Runtime Environment (build 1.6.0_07-b06-153)
Java HotSpot(TM) 64-Bit Server VM (build 1.6.0_07-b06-57, mixed mode)
garfunkel:lib dave$ java -version
java version "1.5.0_16"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_16-b06-284)
Java HotSpot(TM) Client VM (build 1.5.0_16-133, mixed mode, sharing)
Looks like 64bit support might be the issue here.....
It looks like this might be the issue - my macbook has no c2d and thus no Java6 :-(
But you can still hardcode the path to java in the rhq-agent.sh script via JAVA_HOME and RHQ_AGENT_JAVA_HOME (or only the latter) to use the 1.5 java version from System/Library/Frameworks/JavaVM.framework/Versions/1.5/Home
The mac java executable also has a -d32 switch that might help here while still using java 6
But you can still hardcode the path to java in the rhq-agent.sh script
For the record, now that agent auto-update feature is complete, we do not recommend editing "rhq-agent.sh" anymore. If you ever want to customize the environment to the agent (such as setting these Java env vars), modify "rhq-agent-env.sh" instead. Changes to rhq-agent.sh will be lost when you upgrade the agent (because the agent upgrade will install the new rhq-agent.sh version, in the case when we do bug fixes and enhancements to that script), but changes you make to rhq-agent-env.sh will not be lost.
There is a small bug with the rhq-agent.sh script. It tries to set the environment from ./rhq-agen-env.sh which won't work if you've launched the agent from outside the bin directory. Changing to this works from any location:
RHQ_ENVIRONMENT=`dirname $0`/rhq-agent-env.sh if [ -f "$RHQ_ENVIRONMENT" ]; then echo "Loading script environment from rhq-agent-env.sh..." . $RHQ_ENVIRONMENT fi
We've tested this before - what version of the agent do you have? I'm thinking you might have an older version.