I am running into a problem while using waitFor command on a process. My code is like this
//preconditions
try{
// lock the work station
Process p= Runtime.getRuntime().exec("C:\\Windows\\System32\\rundll32.exe user32.dll,LockWorkStation");
int exitval=p.waitFor();
// If the authentication is successful
if(exitval==0)
{
//statements to insert into database
}
}
catch(IOException e)
{
e.printStackTrace();
}
catch (InterruptedException e) {
e.printStackTrace();
}
The process is locking the screen fine, but it is exiting before the user is actually able to authenticate with an exit value of '0' and the program is inserting the statements into my database. I want the process to wait until the user has been successfully authenticated and then insert my data into the database. I've googled for a quite a bit without any success. Should I use a different process to lock the screen?
Under the covers the following is being called when executing LockWorkStation. Note, that it executes asynchronously
BOOL WINAPI LockWorkStation(void);
If the function succeeds, the return value is nonzero. Because the function executes asynchronously,
a nonzero return value indicates that the operation has been initiated. It does not indicate whether
the workstation has been successfully locked.
Also, in your code above you need to execute the process.
In the presented in your question, change:
Process p= Runtime.getRuntime().("C:\\Windows\\System32\\rundll32.exe user32.dll,LockWorkStation");
int exit = p.waitFor();
to
Process p= Runtime.getRuntime().exec("C:\\Windows\\System32\\rundll32.exe user32.dll,LockWorkStation");
int exit = p.waitFor();
Also, you might want to look into using ProcessBuilder instead of Runtime.exec()
LockWorkStation is an asynchronous function. It will always return immediately not waiting for an unlock. When running C:\Windows\System32\rundll32.exe user32.dll,LockWorkStation from the console you might even see the next command prompt shortly before the screen gets locked. In other words, this has nothing to do with Java and Process.waitFor().
Related
Say I have the following code:
try {
//Do something with File
} catch (FileNotFoundException e) {
outputInfo("Error in IO Redirection", true);
e.printStackTrace();
System.exit(1);
}
My program exits right after this catch location, is a single thread (one main method) program and should not expect to recover from such an exception.
Should I really be using System.exit(1); ?
If you expect someone else to run your program, and they rely on the process status code to know if your program has succeeded or failed, then you should use System.exit(1);
http://docs.oracle.com/javase/7/docs/api/java/lang/System.html#exit%28int%29
Terminates the currently running Java Virtual Machine. The argument
serves as a status code; by convention, a nonzero status code
indicates abnormal termination.
One of the reasons to use a non zero exit code on failure of an application is that they can be used in batch files. If your application is a console application always use proper exit code. You don't know how it will be used in future.
I have a Thread (let's say T1) which reads data from socket:
public void run() {
while (running) {
try {
BufferedReader reader = new BufferedReader( new InputStreamReader(socket.getInputStream()) );
String input = reader.readLine();
} catch (IOException e) {
e.printStackTrace();
}
}
}
Another Thread (lets say T2) try to finish the program in one of its method. Therefore T2 does the following:
T1.running = false;
socket.close();
Here is this scenario for which i couldn't find a solution:
T1 is active and waiting for some input to read i.e. blocking.
context switching
T2 is active and sets running to false, closes the socket
context switching
because T1 was blocking and T2 closed the socket, T1 throws an Exception. What i want is to catch this SocketException. i can't put a try/catch(SocketException) in T1.run(). So how can i catch it in T1's running-method? If it's not possible to catch it in T1's running, then how can i catch it elsewhere?
PS: "Another question about the Thread Debugging"
Normally when i debug the code step by step, i lose the 'active running line' on a context switch. Let's say i'm in line 20 of T1, context switch happens, let's assume the program continues from the 30.line of T2, but the debugger does not go/show to the 30.line of T2, instead the 'active running line' vanishes. So i lose the control over the code. I use Eclipse for Java and Visual Studio for C#. So what is the best way to track the code while debugging on a context switch ?
For your problem assuming you are using a Thread Pool maybe you should make a ThreadFactory that installs a Thread.UncaughtExceptionHandler on all Threads and then invoke your work with execute() on the ExecutorService instead of submit().
For you problem with debugging maybe you should read
http://msdn.microsoft.com/en-us/library/ms164746.aspx
Your code has several other problems so I'll address them all at the same time.
You must create the BufferedReader outside the loop. Otherwise you will lose data in the buffers being discarded each time around the loop.
You must test the result of readLine() for null. If you get it, you must close the BufferedReader and exit the loop.
If you get any exception you must also close the BufferedReader and exit the loop.
What i want is to catch this SocketException.
So catch it.
I can't put a try/catch(SocketException) in T1.run().
You must. No choice. You have to completely rewrite it anyway because of the above items.
When I use 4 threads for my program there is usually no problems, but today I increased it to 8 and I noticed 1-3 threads stop working without throwing any exceptions. Is there anyway to find out why they are stopping? is there anyway to make the thread restart?
This is how the structure of my thread is
public void run()
{
Main.logger.info(threadName + ": New Thread started (inside run)");
while (true)
{
try
{
//all my code
//all my code
//all my code
}
catch(Exception e)
{
Main.logger.error("Exception: " + e);
try
{
Thread.sleep(10000);
}
catch (InterruptedException e1)
{
e1.printStackTrace();
}
}
finally
{
try
{
webClient.closeAllWindows();
Thread.sleep(3000);
Main.logger.info(threadName + ": Closed browser!");
}
catch (Exception e)
{
Main.logger.error("Exception: " + e);
}
}
}// end while
}
Regards!
Note that an Error is not an Exception; it's a Throwable.
So, if you catch Exception, Errors will still get through:
private void m() {
try {
m(); // recursively calling m() will throw a StackOverflowError
} catch (Exception e) {
// this block won't get executed,
// because StackOverflowError is not an Exception!
}
}
to catch "everything", change your code to this:
try {
...
} catch (Throwable e) {
// this block will execute when anything "bad" happens
}
Note that there might be little you can do if an Error occurs. Excerpt from javadoc for Error:
An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch. Most such errors are abnormal conditions. The ThreadDeath error, though a "normal" condition, is also a subclass of Error because most applications should not try to catch it.
Is there anyway to find out why they are stopping?
That's a bit tricky.
A Java thread can terminate for two reasons:
it can return from its run() method,
it can terminate due to an exception being thrown and not caught on the thread's stack.
You can detect the latter case by using an "UncaughtExceptionHandler" for the thread, but the former case can't be positively detected unless you modify your thread's run() method to log the event ... or something like that.
I guess, the other way to figure out what is going on would be to attach a debugger to the JVM and get it to report the uncaught exception to you.
(I suspect that the reason you are not seeing any exceptions is that your threads' run methods are not catching / logging all exceptions, AND they don't have an uncaught exception handler.)
is there anyway to make the thread restart?
No. There is no way to restart a Thread that has terminated.
If you are running from the command line, you can have dump states of all threads to the console. On windows you do this by hitting Ctrl+Break, under linux, by sending the QUIT signal to the process with 'kill'.
Please refer to An Introduction to Java Stack Traces
Sending a signal to the Java Virtual Machine On UNIX platforms you can
send a signal to a program by using the kill command. This is the quit
signal, which is handled by the JVM. For example, on Solaris you can
use the command kill -QUIT process_id, where process_id is the process
number of your Java program.
Alternatively you can enter the key sequence \ in the window
where the Java program was started. Sending this signal instructs a
signal handler in the JVM, to recursively print out all the
information on the threads and monitors inside the JVM.
To generate a stack trace on Windows 95, or Windows NT platforms,
enter the key sequence in the window where the Java
program is running, or click the Close button on the window.
Thread priority on one of them could be too high, try setting them the same level through?
Deadlocking is possible if there is any control on each and other between them.
Here's my scenario:
process A spawns child process B and spins threads to drain B's outputs.
process B spawns daemon process C and drains its outputs, too.
process B finishes, daemon process still lives.
process A finds out that process B exited via process.waitFor(). However, it's stuck on reading the input streams of process B. It's because B has started a daemon. The input stream receives EOF only when the process C exits.
This only happens on Windows. I'm using the ProcessBuilder. Here're the solutions I came up with and I'd like to hear your feedback as none of the solutions I really like:
I can use jna to spawn the daemon process C. This way I can create a process that is 'detached enough' and process A is not stuck on draining the streams from B. It works but I'm not very keen on that solution because it means some native code (and lots of that since I'm keen on consuming the inputs). Some inspiration how to do it via JNA is here: http://yajsw.sourceforge.net (however it contains way more stuff than mere process starting).
Run on jre7. Jdk7 brings some new goodies to the ProcessBuilder, e.g. inheritIO() stuff that also solves my problem. Apparently, when inheritIO() is turned on, I can simply close all streams in the daemon process C (which I do anyway because it'a daemon) and that solves the problem. However, I need to run on jre5+
Close the System.out and System.err in process B before spawning the daemon process C. Again, it solves the problem but I really need those streams to work in process B as I write useful stuff to them. No good. I hoped I could take advantage of this characteristic by placing some kind of a bootstrap process between B & C but that didn't solve the problem.
I don't have that problem on linux so could I only run on linux? No, I can't.
Made the process A drain the outputs of process B in a non-blocking way. This somewhat works but it's not convenient. E.g. inputStream.read() is not interruptible. I could use inputStream.available() but it doesn't distinguish between EOF and zero-bytes-available. So the solution is only good if process A is never interested in B's output EOF. Also, this solution seems to be more CPU intensive and generally... feels awkward and not really bullet proof.
Run process C in a --dry-run mode where it just checks if it can be started. It tries to start, sends welcome message and exits. It's no longer long-running so it will not block reads. Process B can gain enough confidence that C can be started and we can use relatively simple JNA code to spawn detached process without consuming its outputs (it's the consuming of outputs makes the JNA-related code messy and heavyweight). The only problem is that we no longer consumer process' C outputs but it can be solved by making C write to a well known file that process B can consume. This solution is more like a big and ugly workaround but kind of workable for us. Anyways, we are trying the solution 1) at the moment.
I would really appreciate any hints!
I just encountered the same problem. I think I have a workaround to the problem. In process A, I have the following code fragment after Process.waitFor(), where outT and errT are the threads to read process B's stdout and stderr, respectively:
try {
outT.join(1000);
if (outT.isAlive()) {
errmsg("stdout reader still alive, interrupting", null);
outT.interrupt();
}
} catch (Exception e) {
errmsg("Exception caught from out stream reader: "+e, e);
}
try {
errT.join(1000);
if (errT.isAlive()) {
errmsg("stderr reader still alive, interrupting", null);
errT.interrupt();
}
} catch (Exception e) {
errmsg("Exception caught from err stream reader: "+e, e);
}
p.destroy();
Not sure if p.destroy() is needed, but I have been trying all kinds of combinations to deal with the problem.
Anyway, in the run() method of the outT/errT threads, I have the following, where the 'pipe' variable is a Writer instance I am capturing stdout/stderr of the sub-process to. The 'in' variable is the stdout, or stderr, stream obtained from Process:
try {
r = new BufferedReader(new InputStreamReader(in, enc));
String line;
while (true) {
if (Thread.currentThread().isInterrupted()) {
errmsg("Text stream reader interrupted", null);
break;
}
if (r.ready()) {
line = r.readLine();
if (line == null) {
break;
}
pipe.write(line);
pipe.write(SystemUtil.EOL);
if (autoFlush) {
pipe.flush();
}
}
}
pipe.flush();
} catch (Throwable t) {
errmsg("Exception caught: "+t, t);
try { pipe.flush(); } catch (Exception noop) {}
} finally {
IOUtil.closeQuietly(in);
IOUtil.closeQuietly(r);
}
It seems that I never get an EOF indication from any sub-process, even after the sub-process terminates, hence, all the chicanery above to prevent stale threads and blocking.
Runtime.getRuntime.exex("abc.exe -parameters");
using .waitFor() does not help to determine the completion of process.
Looks like JDK8 introduces Process.isAlive(). Surprised it took so long...
In the meantime, the best option seems to be to poll Process.exitValue(), wrapped in a try-catch:
// somewhere previous...
String[] cmd = { "abc.exe", "-p1", "-p2" };
Process process = Runtime.getRuntime.exec(cmd);
// call this method repeatedly until it returns true
private boolean processIsTerminated () {
try {
process.exitValue();
} catch (IllegalThreadStateException itse) {
return false;
}
return true;
}
Alternately, a similar method could return the exit value if the process had terminated, or some other specified value if not.
Process.waitFor() (javadoc) should work. If it doesn't work then either:
there's a bug in the JVM or the OS (highly unlikely for something like this), or
there is something about the process and/or your Java code that means that the process won't exit.
In current releases of Java you can also use Process.isAlive (javadoc) to test the process status without blocking until it finishes. For Java 7 and older there is a hacky solution that entails polling the process return code and catching an exception, but this is inefficient. You should upgrade to Java 8 or later as soon as possible!
Once the task is finished its goes for an indefinite wait. (I don't know why).
If this happening, then neither waitFor() or isAlive() will help.
The most likely reasons that a process launched from Java won't / can't exit are:
the process is blocked waiting for your Java application to give it some input (via its stdin),
the process is blocked waiting for your Java application to read its output (i.e. its stdout or stderr),
it is blocked waiting on some external event; e.g. if it is trying to talk remote server that is not responding,
something has sent it a STOP signal of some kind, or
it is just taking a looong time to run.
The first two of these reasons / causes can be addressed by (respectively) closing the Java output stream connected to its standard input, and reading (and possibly discarding) the Java input streams connected to its standard output and standard error. The other causes are intractable, and your only options are to "wait it out" or attempt to kill off the process.
Bottom line - you need to find out why your process isn't completing. The blocked Process.waitFor() call is a symptom, not the disease.
I have a similar issue and neither of the methods written here works for me. This is my code:
public void startCCleaner() {
System.out.println("Starting ccleaner...");
try {
Process process = new ProcessBuilder("C:\\Program Files\\CCleaner\\CCleaner64.exe").start();
if(process.waitFor() == 0 ){
System.out.println("Process terminated ");
}
} catch (IOException e) {
e.printStackTrace();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
If you don't want to use waitFor(), which apparently you don't you can always test the exit value directly.
import java.util.*;
import java.io.*;
public class ProcExitTest
{
public static void main(String args[])
{
try
{
Runtime rt = Runtime.getRuntime();
Process proc = rt.exec("<....>");
int exitVal = proc.exitValue();
System.out.println("Process exitValue: " + exitVal);
}
catch (InterruptedException ie)
{
ie.printStackTrace();
}
}
}
exit code 0 means normal termination.