Hi all i Have two process in my java application as below.
Process p1=some process;
Process p2=some process;
At the first time it starts its working perfectly.But when i reload the application the older process is also running so i just want to kill the older process if its executing.I know that we can kill a process by using its process id.But how can i get the process id of this p1 and p2.Any idea?.
Catch the reload event in your application and terminate the child process before you exit.
If that doesn't work, you probably have a bug in your design. Try to fix that bug. Really. I mean it.
A workaround is to write the PID into a text file. When you start, read the text file, check if this is the correct process and then kill it.
Without the check, you might be killing a perfectly valid process which was created by someone else. My reasoning is like so: You can't kill the process when you reload. That means you can't delete the text file either. So the PID file will always exist. Eventually, you will kill the wrong process. That will happen once per year. It will happen the first time six months after you left/changed job/etc. Nobody will understand what is going on because it's almost impossible to reproduce.
As others have said, it would be better to terminate the process in a more natural way.
However, if you do need to actually forcibly terminate it, then you could call the destroy() method on the Process object, whenever you don't care about it running anymore.
Also, do you really need to run the code as a Process? There are generally better ways.
Related
I am working on fixing a bug that makes our CI/CD pipeline fails. During an integration test, we spin up a local database instance. In order to do this, we are using some mariadb wrappers to launch it from a java codebase.
This process can (potentially) take a long time to finish, which will cause our tests to timeout. In this case, we have added a functionality to kill a process if it cannot install within 20 seconds and should try again.
This part seems to be working.
The strange bit comes when trying to destroy the process. It seems to randomly take ~2-3 MINUTES to be unblocked. This is problematic for the same reason that the above problem was problematic.
Upon investigation into the underlying libraries, it seems like we are using ExecuteWatchdog to manage the process. The is a bit of code that is blocking is:
watchDog.destroyProcess();
// this part usually returns nearly instantly
try {
// this part can take minutes...
resultHandler.waitFor();
} catch (InterruptedException e) {
throw handleInterruptedException(e);
}
In addition to this, there is different behavior on Mac/Linux. If I do something like resultHandler.waitFor(1000) // Wait with 1000ms timeout before just exiting, it will work fine on a macbook, but on linux i see an error like: java.io.FileNotFoundException: {{executable}} (Text file busy)
Any ideas on this?
I have done some research and it seems like watchDog.destroyProcess is sending a SIGTERM instead of a SIGKILL. But I do not have any hooks to get the Process object in order to send it the KILL instead.
Thanks.
A common cause for blocking when working with processes is that the process is blocked on output, either to stdout or (the more likely to be overlooked) stderr.
In this context, setting up tests on a CI server, you might try setting the output and error output to INHERIT.
Note that this means that you won't be able to read the sub-process output or error stream in your Java code. My assumption is that you aren't trying to do that anyway, and that's why the process hangs. Instead, that output will be redirected to the output of the Java process, and I expect your CI server will log it as part of the build.
So I am trying to have a Java program that starts running when the main method is invoked and stops running when the same main method is invoked (from another process). So the goal is to kill the first process with the second process, and then kill itself.
What I have tried are the following:
taskkill for Windows and kill for Unix.
This is the simplest way to do achieve the goal. But the process in Windows is always javaw.exe and calling taskkill would terminate other JVMs.
ServerSocket or DatagramSocket, to tell the first process to kill itself.
This works as well but I feel like this is just a waste for such a simple job.
File locks
The problem is that the permission of creating a file is not always granted (for whatever reason someone decides to use the program in read-only folders).
I think I might just missed something obvious. Any suggestions would be appreciated.
I have a init.d script which starts/stops a jruby based server running on java 8. It first does it the nice way with a kill and then after a while it falls back to a kill -9. I can see from my logs that the kill triggers the right shutdown hooks and eventually it calls System.exit(0). At this point the process should die, except it doesn't.
I've actually polled with a loop inside my init.d script whether the process still exists at that point (yes) and tried with a kill -QUIT to make it log a thread dump. The latter stops working after a few seconds but the process zombies along until I kill -9 it.
My question: how can I determine what is causing this? At least a thread dump would tell me what part of my code is blocking but it seems to be in a state where that no longer works and yet the process does not exit.
The suggestion by Joe to use Runtime.getRuntime().halt(int) works. Thanks
I am working in an java application where i want to make sure that a given process in the computer is idle
ex:- if we start a download process in our computer my application should be able to monitor it (process) and tell when it is over,
Most operating systems provide user commands to monitor activity of a process, like CPU or I/O. Or, at a higher level, you can get the status (running or not) of a process by its process identifier. You could exec these tools from Java, but there's nothing in core Java to do this, nor am I aware of any libraries for this purpose.
However, if you are thinking about killing a process because it is "idle", that generally wouldn't be safe. You have to know enough about the process in question to be sure it's okay to kill it, and if you know that much about it, you'll probably find that there's a way to get it to shut itself down cleanly.
If you start the process from another process, you can detect when it finishes with Process.waitFor() You can even use its exit code.
I need to spawn a process in Java (under Linux exclusively) that will continue to run after the JVM has exited. How can I do this?
Basically the Java app should spawn an updater which stops the Java app, updates files and then starts it again.
I'm interested in a hack & slash method to just get it working as well as a better design proposal if you have one :)
If you're spawning the process using java.lang.Process it should "just work" - I don't believe the spawned process will die when the JVM exits. You might find that the Ant libraries make it easier for you to control the spawning though.
It does actually "just work", unless you're trying to be clever.
My wrapped java.lang.Process was trying to capture the script's output, so when the JVM died, the script didn't have anywhere to send output so it just dies. If I don't try to capture the output, or the script doesn't generate any or redirects everything to a file or /dev/null, everything works as it should.
I was having trouble with this and the launched process was getting killed when the JVM shutdown.
Redirecting stdout and stderr to a file fixed the issue. I guess the process was tied to the launched java app as by default it was expecting to pass its output to it.
Here's the code that worked for me (minus exception handling):
ProcessBuilder pb = new ProcessBuilder(cmd);
pb.redirectOutput(logFile);
pb.redirectError(logFile);
Process p = pb.start();
I thought the whole point of Java was that it's fully contained within the JVM. It's kinda hard to run bytecode when there's no runtime.
If you're looking to have a totally separate process you might look into trying to start a second java.exe instance. Although for your application, it might be easier to simply make a synchronized block that stops (but doesn't kill) your app, does the updating, and then re-initializes your app's data.
It won't always "just work". When JVM spawns the child and then shuts down, the child process will also shutdown in some cases. That is expected behaviour of the process. Under WIN32 systems, it just works.
E.g. If WebLogic server was started up by a Java process, and then that process exits, it also sends the shutdown signal to the WebLogic via shutdown hook in JVM, which causes WebLogic to also shutdown.
If it "just works" for you then there is no problem, however if you find yourself in a position that child process also shutsdown with JVM it is worth having a look at the "nohup" command. The process won't respond to SIGTERM signal, but will respond to SIGKILL signal, as well as normal operations.
Update: The way described above is a bit of an overkill. Another way of doing this would be to use "&" on the end of command. This will spawn a new process that is not a child of current java process.
P.S. Sorry for so many updates, I have been learning and trying it from scratch.
>>don't believe the spawned process will die when the JVM exits.
Child process is always dying on my box(SuSE) whenever I kill java. I think, the child process will die if it's dealing with I/O of the parent process(i.e., java)
If you're looking at making an updater on Linux, you're probably barking up the wrong tree. I believe all major linux distros have a package manager built in. You should use the package manager to do your updating. Nothing frustrates me more than programs that try to self-update... (I'm looking at you, Eclipse)