Full story:
I am trying to start up an instance of hudson with a larger memory allocation and I'm currently using scripts owned by root that I can't modify directly to pass arguments. However the script currently passes the $JAVA_ARGS variable when starting up the service. I have exported the required parameters to JAVA_ARGS but the application still appears to be bound by the old memory restrictions.
Question:
Is there a way to find out which command line parameters were used to start up the instance. More specifically I'm looking to find the values that were passed (if any) to Xmx and Xms.
java version "1.6.0_12"
Java(TM) SE Runtime Environment (build 1.6.0_12-b04)
Java HotSpot(TM) 64-Bit Server VM (build 11.2-b01, mixed mode)
After some searching I came about a pretty simple solution (which I'm a little embarrassed to have missed for so long). You can see the command line to any command running in linux with ps, as long as you pass the correct flags. I just made a call to ps -fHu hudson and was able to see the full command line call to java which showed the passed in parameters.
Since you can export $JAVA_ARGS, maybe you can override $PATH to trick the script to run another program instead of the JVM, which could be a program that simply writes its arguments somewhere.
Related
I am trying to diagnose a few issues with ssl connectivity with Leingen. I am trying to find what SSL Key Store and Trust Store is being Used by Leingen,
I am behind a corporate firewall and we have self signed certificates deployed on all our desktops . I am running lein.bat on a windows 10.
Hence I have to start Leingen with java -Djavax.net.debug=true option.
The :jvm-opts in the project.clj wont work -- I need to make sure the Liengen's JVM is started with this option
You can set leiningen JVM options by setting LEIN_JVM_OPTS environment variable before running lein in the same terminal session.
The lein command is just a shell script which eventually invokes java with various options. You can edit this script to see what options are used and/or to modify them.
As Piotrek mentioned, the LEIN_JVM_OPTS environment variable is the canonical way of passing options to the jvm in which lein runs. You can see it used on line 372 of the source code.
For your case:
> export LEIN_JVM_OPTS='-Djavax.net.debug=true'
> lein clean
> lein run
Since you're running windows, you'll want to actually look at the lein.bat file. You'll still need to update LEIN_JVM_OPTS, but how you go about it will be a bit different. If you're using windows command terminal (cmd.exe) you will want to use the set command.
set LEIN_JVM_OPTS="-Djavax.net.debug=true"
The command is likely different if you're using powershell, and you can likely find out how to set that on this page on environment variables.
Background
I have a C++ program that loads a JVM internally and then uses JNI to call code in the JVM. This runs on multiple platforms including AIX. However, when starting the JVM on AIX everything is fine until I call some code that needs to access native code supplied as part of the JRE. I then run into this error message:
java.lang.UnsatisfiedLinkError: net (Not found in com.ibm.oti.vm.bootstrap.library.path)
The problem is that the JVM cannot find the shared library libnet.so. If I dump the value of the com.ibm.oti.vm.bootstrap.library.path system property from Java code running in the JVM I see that by default (i.e. not me setting it) it has the value:
<jre-base-dir>/lib/ppc/default:<jre-base-dir>/lib/ppc
From the error message I guessed it would be a good idea to change this to include the dir where libnet.so is located. However, this shared library is in <jre-base-dir>/lib/ppc which is already in the path set by com.ibm.oti.vm.bootstrap.library.path, so it seems the error message is incorrect.
Experimenting with different values for this system property makes me believe that it is used by the AIX j9vm to load the internal JVM shared libraries only (like libjclse7b_26.so) but not the native code implementations (like libnet.so).
My fix
To fix my problem I had to change the LIBPATH environment variable (which is AIX the equivalent of LD_LIBRARY_PATH in e.g. Linux).
$ LIBPATH=<jre-base-dir>/lib/ppc:<jre-base-dir>/lib/ppc/j9vm ./myprogram
Questions
Can anyone shed some light on the real purpose of the system property com.ibm.oti.vm.bootstrap.library.path on AIX when using the j9vm JVM?
Is my fix the correct way to solve the problem or should I use some other system property? (I have tried java.library.path but it does not seem to help.)
In my case it show error message:
java.lang.UnsatisfiedLinkError: awt (Not found in com.ibm.oti.vm.bootstrap.library.path)
I fix my problem by
copy /usr/java6_64/jre/lib/ppc64/libawt.so to /usr/java6_64/jre/lib/ppc64/j9vm and create symbolic link libawt.a to libawt.so
I set LD_LIBRARY_PATH
LD_LIBRARY_PATH="/usr/java6_64/jre/lib/ppc64:/usr/java6_64/jre/lib/ppc64/j9vm"; export LD_
LIBRARY_PATH
I struggled on this issue for a few days but didn't get a right answer yet.
Here is the Problem Description:
I wrote a normal Java program (Program-A), and wrote a Windows-based native agent (*.dll, written in C/C++) with Agent_OnLoad, Agent_OnAttach, Agent_OnUnload method, which works fine if using Java command-line flag (-agentlib). Then I wrote another Java program to attach the native agent onto a runing the Java Program-A (see the below code piece for VM attach and loadAgentPath), however I got the exception:
com.sun.tools.attach.AgentLoadException: Failed to load agent library
I tried to change the agentPath (absolute or relative file path) this or that way, none of these works. Should I try some other way to make this work. What I need is to attach a native agent onto a runing java program rather than using command-line flag.
Does anyone know the root cause or a clue for the solution?
BTW, the command line to run attach VM Java code as:
java -Djava.library.path=D:\DevTools\Java7\jre7\bin -classpath .;./tools.jar com.xxx.TestAgentVMAttacher
...
VirtualMachine virtualMachine = com.sun.tools.attach.VirtualMachine.attach(pid); // Note: this code line is executed normally, I am sure the pid is correct
...
agentPath = theFilePath + "/myagent.dll"; // Note: I am sure the dll file path is correct
virtualMachine.loadAgentPath(agentPath,null); // Note: this code line would cause the exception (AgentLoadException) as I mentioned above, no matter how I set the agentPath, even I set it as null, same exception happened.
Environment related info:
- OS: Windows XP
- Java Version: Java(TM) SE Runtime Environment (build 1.7.0-b147)
Eventually I found the answer for my question, I had a wrong method name ('Agent_Attach') in Agent.cpp file, the correct one should be 'Agent_OnAttach', with this fix, my agent lib (.dll) can be loaded to a running Java program now.
That is the question: my Java application is running, so how to get the path/name to the java binary that is running it? For example, 'C:\Program Files\Java\jre6\bin\java.exe' in Windows or '/usr/bin/java' in Linux. I need a platform independent solution, preferably relying only on the JDK.
The context for the question is the following. I'm developing two Java applications, let's say FirstApplication and SecondApplication. The FirstApplication will start the SecondApplication using the ProcessBuilder API. The problem is that I need to tell the path to the Java binary to start the SecondApplication. For example,
String cmd = "C:\Program Files\Java\jre6\bin\java.exe -cp <second application classpath> com.secondapplication.MainClass";
Process p = new ProcessBuilder(cmd).start();
Possible alternative solutions to this could be assume that there is a java binary available through the PATH system variable, or assume that the JAVA_HOME system variable is set. But this may not be always the case. Also, the final user of the application (targeting to other Java developers, as well as final users) may have more than one JVM installed on his system, and may execute the FirstApplication expliciting what JVM he wants. Ideally, the SecondAplication should run using the exact same Java binary as the FirstApplication, without relying on such system variables.
Thank you
I have a third party library that I'm attempting to incorporate into a simulation. We have the static library (.a), along with all of it's runtime dependencies (shared objects). I've created a very simple application (in C) that is linked against the library. All it does is call an initialization function that is part of the third party library's API, and exits. When I run this directly from the command line, it works fine. If I submit the executable to our Condor grid, it fails with a seg fault on strncpy (libc.so.6). I've forced condor to only run the executable on a particular machine, and if I run it directly on that machine, it works fine.
I'm mostly a Java programmer... limited amount of native coding experience. I'm familiar with tools such as nm, ldd, catchsegv, etc... to the point where I can run them. I don't really know where to start looking for an issue though.
I've run ldd directly on the executing machine, and via a script submitted through condor, along with my executable. ldd reports the same files in both cases.
I don't understand how running it directly would work, but it would fail being run by condor. The process that ultimately executes the program, condor_startd, is a process that starts as root, and changes its effective uid to the submitter. Perhaps this has something to do with it?
Don't know why this would cause an issue, but the culprit was the LANG environment variable. It was not set when running under Condor, but was set to US_EN.UTF-8 when running locally. Adding this value to the condor execution environment fixed the problem.