Develop Reference

How to know what program a java process is running [duplicate]

Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 10 years ago.
Improve this question
When a java based application starts to misbehave on a windows machine, you want to be able to kill the process in the task manager if you can't quit the application normally. Most of the time, there's more than one java based application running on my machine. Is there a better way than just randomly killing java.exe processes in hope that you'll hit the correct application eventually?
EDIT: Thank you to all the people who pointed me to Sysinternal's Process Explorer - Exactly what I'm looking for!

Run jps -lv which shows PIDs and command lines of all running Java processes.
Determine PID of the task you want to kill. Then use command:
taskkill /PID <pid>
to kill the misbehaving process.

Download Sysinternal's Process Explorer. It's a task manager much more powerfull than Windows's own manager.
One of it's features is that you can see all the resources that each process is using (like registry keys, hard disk directories, named pipes, etc). So, browsing the resources that each java.exe process holds might help you determine wich one you want to kill. I usually find out by looking for the one that's using a certain log file directory.

If you can't run a GUI application like ProcessExplorer and you're looking for the "Command Line" arguments of the processes then you can use "wmic" via the command line. For example:
wmic PROCESS get Processid,Caption,Commandline
If you want to look for a specific process you can do this:
wmic PROCESS where "name like '%java%'" get Processid,Caption,Commandline
The output from this will show you all of the command line arguments of processes like "java."

Using jps in the JDK will give you more information. More information is display with the -m, -l and -v options.

Have you tried using Process Explorer from SysInternals? It gives a much better idea of what is running within the process. Available free online here: http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx

If you're using Java 6, try jvisualvm from the JDK bin directory.

You could try opening Windows Task Manager, going to the Applications tab, right clicking the application and then selecting "Go To Process". This will automatically highlight the appropriate process in the Processes tab.

In case you're developing software: use a java-launcher. I used for a few of my application [Exe4j][http://www.ej-technologies.com/products/exe4j/overview.html] and it worked very well. When the application is started, it's listed as for example "myserverapp.exe" or "myapp" in the windows tasks manager.
There are other lauchers too (don't known them by heart), few of them might be for free too.

I'd suggest downloading Process Explorer from Sysinternals and looking at the different java.exe processes more closesly, that way you can get a better idea of which one to kill.
http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx
It's very intuitive and you can find the java.exe processes and right click and goto their properties, from there you can see their command line, time of creation, etc which can help you find the process you want to kill.
Hope it helps.

Using ProcessExplorer and hovering over the Java process will show the command line.

If the application is not responding at all, then Process Explorer is a good option.
If it's sort of responding, but not dying, sometimes bringing up task manager, and then moving another dialog over the java process will give you a clue. The java process that's taking up cpu cycles to redraw is the one you're looking for.

Rather than using a third party tool, you can also make a pretty good guess by looking at all the columns in task manager if you know roughly what the various java processes on your system are. From the Processes tab, use View-> Select Columns and add PID, CPU Time, VM Size, and Thread count. Knowing roughly what the process is doing should help narrow it down.
For example, in a client-server app, the server will likely use more memory, have more threads, and have used more CPU time because it has been running longer. If you're killing a process because it's stuck, it might simply be using more CPU right now.
MAX java heap memory is usually directly reflected in VM Size. So if you're using -Xmx flags, the process with the larger setting will have a larger VM Size.

How to automatically kill orphaned Java processes

I've posted this question before, but didn't get the answer I wanted. The problem I have right now is that there are a number of Java processes getting orphaned. This is both on Linux and Windows. I need a way to FIND which Java processes are the ones that are orphaned and kill them.
NOTE: I CANNOT make changes to the Java code as I have no access to it on any level. I am simply running some tests on my machine. I am aware of solutions like this one
Killing a process using Java
but that is not what I am looking for.

On Linux an orphaned process becomes the child of init, which always has pid 1. To kill java processes that are children of init you can use pkill:
pkill --parent 1 java
To make this automatic you can add this command to cron, for example.

How to automatically run java function/program on server

I have written a code to send mail to user and that's running nicely, but this program i want to place on server side and runs continuously without any client interaction. It should be run automatically after specific time. When server stops then only it will stop.
So can any one help me how to do this...?
Thanks in Advance...

If your server has cron, you can have the job run at scheduled times. Without knowing more about how the application works, and how it knows when it's time to send an email, there's not much more I can say.

You should look at the Quartz and how to start a java process from the command line in your deployment environment (it's slightly different in Windows and *nix, and very different in z/OS).

If I understood correctly, in your case I would just use the at command. You can find a description in its man page1.
Probably calling at with a calculated time from the moment of execution, and adding that to a rc.d script would do it.

How To Start Jetty Properly

this really silly question probably, as no one else seems to be having this problem. In the Jetty documentation it says jar -jar start.jar starts Jetty, and it does. But when I close my SSH console, obviously it dies.
How do I run it PROPERLY?

Is this for running on a production machine that will actually serve up an application running under Jetty? I assume this is the case, since you're asking about starting it properly.
If so, you need a proper process supervision system, such as runit, daemontools, monit, upstart, systemd, or good ol' SysV init.d (as mentioned w/ a gist). Which to use depends on your preferences, business needs, and often, your underlying operating system.
I use and prefer runit. It is built on solid principles (daemontools), and for my preferred distribution (Debian and Ubuntu) it is nicely packaged by the author himself.
Despite being recommended in other answers, and mentioned in comments, starting a long running process in screen/tmux, or via nohup is sub-optimal. You don't have any real control over the process. It won't be restarted if it dies. You have to manually find its PID and otherwise manually manage the service. You have to do more manual work to get the log output (redirection, sending to some random file, etc). You cannot reliably make it depend on other processes, or have other processes depend on it. Decent process supervision systems provide all this functionality for you by default.
If your goal is something else entirely, then please update the question to be more specific about your use case.

java -jar start.jar &
(to run in the background) should also work, though logging won't be transmuted as nice as w/nohup.
This is because killing the shell that started a process (e.g. by logging out) will kill process to unless they're background processes. Screen works since as well since it runs in the background, and screen effectively keeps your session running while you attach/detach.

One way is to use nohup
nohup java -jar start.jar
This has the advantage of writing stdout and stderr to a file
Another way would be to use screen

If you're on a *nix system, the best solution is may be using a script in /etc/init.d (or whatever your system's equivalent is). There's one at https://gist.github.com/404672.
Otherwise, using nohup or screen from the command-line will at least have the process not die when you log out. So will putting the process in the background with &.

The shutdown hook isn't executed when the application is launched using javaw.exe

If I'm using javaw.exe to launch a Java application, the shutdown hook isn't executed when users log off from their Windows account. The application is actually launched using a launch4j generated .exe file but I know it uses javaw.exe to start it.
This seems to be a known bug:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4302814
Has anyone else had this problem? If so, how did you fix it?
Thanks!

The application is actually launched using a launch4j generated .exe file but I know it uses javaw.exe to start it.
I haven't used launch4j in a while, but I'd be fairly suprised if it directly did this. Most of these apps start the jvm themselves, rather than shelling out to javaw.
The only difference between java.exe and javaw.exe is that java.exe automatically attaches a console. The bug that you reference (and the others referenced by it) were closed as Sun doesn't appear to be interested in making the handling of Windows logoff events better. From what I can tell, it only works with java.exe, because the console itself handles the WM_MESSAGES in such a way that it slows down the shutdown process.
It appears that the only easy workaround at the moment is to change the "headerType" in your launch4j config to "console". Obviously, this brings with it an ugly console.
I think the other alternative would be to use some sort of native wrapper of your on that handles windows messages in a cleaner way.