Process.destroy() on Linux does nothing

[Anonymous]

I've got a piece of code which starts an external process and kills it later on. This works perfectly on Windows, but on Linux the process is started but not destroyed. It's like as if I didn't call destroy() at all.

This is the code:

//final String EXECUTABLE = "taskmgr";  // for windoze
final String EXECUTABLE = "ksysguard";  // linux
 
Process process = null;
boolean success = false;

try {
process = Runtime.getRuntime().exec(EXECUTABLE);
success = true;
} catch(IOException ex) {
ex.printStackTrace();
success = false;
return;
}
 

// wait 
final int WAIT_TIME = 8000;
Thread.sleep(WAIT_TIME);
 
System.out.println("before destroy(): " + process);
process.destroy();
System.out.println("after destroy()");
  

Any ideas?
I'm using JRE 1.5.0 for both Linux and Windows.
Thanks in advance!
Dennis

[Vlado Zajac]

It works for other programs, just not with ksysguard. At least on my Mandrake 10.1.

[M Beck]

run ksysguard from the command line, and you'll get a good clue as to why: this program detaches itself from the starting PTY, and puts itself into the background. to end it, you may have to explicitly kill it; sending it a SIGHUP seems to be sufficient.

(translation for non-Linuxites: run "/usr/bin/kill -1 [PID]" on its process ID. unfortunately, i do not know how to get the PID of a Process object in Java - it ought to be simple, but i don't see a method for doing it in the API.)

[Anonymous]

alright, thanks guys. i didn't notice at all.
all KDE apps seem to do this, but I don't like it. in fact I tried to get the PID as well but there really seems to be no way to do it.
running a process explicitly in the foreground would solve the problem as well, but I don't know how to do this.
when the process detaches from the shell, it doesn't even go into background mode but becomes a wholly separate process, unrelated to the shell. therefore you can't get the PID via "$!" which, in bash, normally contains the last background process' pid.
I don't know if this problem can be solved, but if you have any ideas (including how to get the PID) I'd be happy!

[Marilyn de Queiroz]

Because this seems to be pretty Linux specific, I'm going to move this to the Linux forum in hopes of getting some useful followup.

[Anonymous]

I just ran into a bash command called "disown" which does exactly that - decouple a process from the shell. I still don't know how to regain control on such a process in Java ..

[M Beck]

"when in doubt, use brute force."

in this case, i guess "brute force" would mean running:

/bin/ps -C ksysguard --no-heading

to find the PID of ksysguard (integer number, first column of the output) and then running "/usr/bin/kill -1 (PID)" on that. it's clumsy, roundabout, and wouldn't be necessary if KDE didn't have this annoying habit, but at least it ought to work.

[Alton Hernandez]

I believe that the problem with ksysguard is that it detaches itself from the parent process and turns into a daemon process. The Runtime.exec will not work well on daemon process as mentioned in the API Doc:

The Runtime.exec methods may not work well for special processes on certain native platforms, such as native windowing processes, daemon processes, Win16/DOS processes on Microsoft Windows, or shell scripts.

[Anonymous]

I like the brute force approach better than giving up, but still, I'm not really happy about it cos using the process name as the key to the PID doesn't seem very robust. as soon as there's another process with the same name, it doesn't work anymore, right? however i'm aware that this is the way it is often done. but it's dodgy!
having some wrapper script etc as a handle to the daemon is what i had hoped to find, or a way to get the PID of the newly created daemon somehow.
thanks anyway guys, but i won't give up now. the task seems too simple!

[M Beck]

Originally posted by Dennis K�hn:
I like the brute force approach better than giving up, but still, I'm not really happy about it cos using the process name as the key to the PID doesn't seem very robust. as soon as there's another process with the same name, it doesn't work anymore, right?

depends on who owns it. if you start another ksysguard, then you'll get two lines of output from that ps command; counting lines of output, then, can serve as a double-check that things are all right.

as it's written right now, that ps command won't (or shouldn't) report any ksysguard's that any other users have running. refer to the man page for ps for more information; there's all sorts of ways to tweak which processes it tells you about and how. ps is a surprisingly versatile tool, really.

[Tim Holloway]

I've had more trouble with Java-to-nonjava (exec) connections that anything else in the Java Universe. Aside from the portability issues, I've a strong suspicion that there's a bug in the Solaris setup we have. At any rate, there are documented (and repeatedly-repaired) cases of problems with how Solaris Java detects and cleans up after exec'ed processes.

Outright killing a process, even entirely within Java is a rude thing to do and can lead to all sorts of obscure problems. If at all possible, try sending the child process some sort of signal and let it terminate itself instead. That way it has an opportunity to shut itself down cleanly.

[M Beck]

Tim's advice is good, in general, providing the child process will respond to such a signal. in fairness, running "kill -1" on a PID is meant to do just that; signal number 1 (the "-1" option) is SIGHUP, or "Hang Up", which is just about the least disruptive of the Unix signals one can send a process. if that doesn't get the thing to exit within a reasonable time, i'd proceed to send a SIGINT (signal #15), followed later by a SIGKILL (#9).

and here's an impromptu trivia quiz for budding Unix specialists: there are (at least) two cases in which even a SIGKILL will not cause a process to disappear from the process list; what are they?

[Francois Roland]

As I've got this problem at work the last week, I think that a process in the waiting state or using ISM could prevent a process to being killed this way.

But I don't have the exact answer... I'm really looking forward hearing yours.

[M Beck]

the answer to my Unix trivia quiz: when a process is in either of states D and Z, it can't be killed even by SIGKILL. (the state a process is in can be displayed by the ps command; see its documentation for details.)

state D is "blocked in kernel mode", which usually means blocked waiting on a device driver to do something - hardware failures can induce this, as can kernel bugs. very occasionally, a process will need the kernel to do something that just plain ends up taking long, for reasons that mean the kernel can't (or won't) simply put the process to sleep (state S) while waiting for the completion; that usually results in a state D.

state Z is "zombie", which means the process is already dead and gone, but its parent process hasn't picked up its exit status yet. since the exit status might be important, a "pseudo-process" is kept around in the process list to store it until some parent process gets around to collecting it. in theory, the init(1) process - PID 1 - should occasionally reap zombies that stick around too long, but init isn't foolproof either, so...

there might be other reasons a process becomes unkillable, i suppose. i don't know of any, but would like to learn if anyone else does!