There are a lot of java processes running on the server, generally, we capture the PIDs of the java processes using command 'ps -ef | grep java'. In general, the java processes have a lot of jars in their structure like the following

java -DCORDYS_INSTALL_DIR=/opt/abcd/clouprod01 \
     -cp "/opt/abcd/clouprod01/scp.jar:/opt/abcd/clouprod01/scp.jar:/usr/lib/mysql-connector-java-5.1.22-bin.jar::/usr/lib/mysql-connector-java-5.1.22-bin.jar: com.eibus.tools.admin.cmc" \

In the above java process, there are a few parameters which are passed as arguments to the java process like "-DProcessName=ABCD".

In my case, for a few java processes, there are almost 50 jar files which get loaded when the java process starts. As a result of that, the result of the ps command is not showing the full structure/stack of the java process. The results are coming like

java -DCORDYS_INSTALL_DIR=/opt/abcd/clouprod01 -cp "/opt/abcd/clouprod01/scp.jar:/opt/abcd/clouprod01/scp.jar:

Can anyone help us in tracing the full structure/stack of the java process using either the ps command or any other command?


On RHEL/CentOS in the bash shell, this is usually the result of ps truncating output. In this case, you can add two 'w's to the ps options to get the full command line:

ps -efww | grep java

There are more than likely similar options available for your ps binary, if the 'w' option doesn't accomplish it or isn't available.


If I understand correctly, you want the full command line of the process.

Under Linux or *BSD, pass ww to the ps command to tell it not to truncate command lines.

ps -A ww

You can extract just the arguments (including the command name) by passing -o args to ps.

ps -o args -A ww

Under Linux, you can pass -C java to list only processes running a command called java.

ps -o args -C java ww

Another way to get unlimited width instead of the terminal width is to pipe through another program.

ps -o args -C java | cat

Under Linux, you can retrieve the whole process command line from /proc/$pid/cmdline where $pid is the process ID. The command line is stored unambiguously, with null bytes to separate arguments, so this is good even if the arguments contain spaces.


Use the /proc filesystem for this sort of thing. In particular, I think you'll want to look at /proc/$PID/maps. "$PID" is the process ID in question. You can use something like cat /proc/$PID/maps to get a text version of what's mapped in where for any given PID. cat /proc/self/maps for starters: that will show you what a simple C program maps in.

I found a "cat" example program in Java, and did java cat /proc/self/maps. That simple "cat" had a large number of ".so" loadable libraries, but only rt.jar mapped in as a .jar file.


If you happen to use Solaris, you can get the full argument list with one of:

/usr/ucb/ps -alxww


pargs $pid

Beware that you'll still get a truncated list for the processes you don't own unless you have extra privileges (typically being root).

Not sure if you really want to get the process stack too but just in case, the command to display it would be (assuming pid is a variable containing the JVM process ID):

pstack $pid
  • hi @jlliagre, i am also using Solaris, but i am not able to get the complete command using Example: bash-3.2$ /usr/ucb/ps -alxwww | grep ftf.sh | head -1 0 39548 737 693 0 23 20 5112 3952 603110c3e70 S ? 248:52 /usr/bin/bash /proj/cmp01/app/ftf/bin/ftf.sh -y -c /proj/cmp01/app/btws/cfg/btw bash-3.2$ Even pargs also not working in my case. bash-3.2$ for i in /usr/ucb/ps -alxww | grep -v "alxww" | grep ftf | grep -v grep| awk '{print $2}'|head -1; do pargs $i; done pargs: cannot examine 39548: no such process or core file – Tingrammer Jul 1 '14 at 5:08

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.