[vox-tech] HOWTO: Get Process ID from inside Java?
Mark K. Kim
vox-tech@lists.lugod.org
Fri, 31 Jan 2003 20:15:23 -0800 (PST)
I have a couple observations:
- Java is cross-platform, but the concept of PID isn't.
(Though most modern OS support it.)
- Java is an object byte-code that runs on a virtual machine,
and it's the virtual machine that has the PID not the
object byte-code, so what does a PID really mean to a
Java program?
Having said all that, can't you use System.getenv("PPID")? Well, I guess
if the answer is that obvious, it'd be on the Internet, huh? Never mind.
-Mark
On Thu, 23 Jan 2003 msimons@moria.simons-clan.com wrote:
> I've been looking for info about getting the process id of a running java
> program from inside java. Amazingly enough it appears that getpid and
> other similar of functions are not available to a native java program.
> After browsing around for an hour I have found five common work arounds
> for this language omission:
>
> - Have a shell script pass into the java process it's own PID on the
> command line: "exec java ClassName $$"
>
> - Fork and exec another process from within the java which echos or
> returns the Parent Process Id for the java process to catch and parse...
> (see method 2)
>
> - Have a shell script which starts the java process save to a text file
> java process's pid, then have java read that file:
> "java ClassName & echo $! > pid.txt"
>
> - Use JNI to call a c stub to invoke the operating system's getpid
> function (method 4);
>
> - Use some form of "ps auxww | grep MagicString" to find the correct
> process id and parse the ps line <bleh>.
>
> ... All of this is just getting too gross for words. I'm wondering if any
> Java guru's out there have found a simple hole in the Java (hide useful
> information from running code) mentality and know of a fairly clean way
> to get the process id of the current running VM.
>
> Thanks,
> Mike
>
>
> In this particular case I would like the process id to use as part of
> a log file name. This is for a java server which is unstable and so
> multiple java process are run at the same time so when one starts getting
> borked it simply needs to be killed (a nanny program will restart dead
> server processes so that the server appears to be stable). ...
>
>
> method 2:
> ===
> try
> {
> Process p = Runtime.getRuntime().exec(
> new String[] {"perl", "-e", "print getppid(). \"\n\";"});
>
> BufferedReader br =
> new BufferedReader(new InputStreamReader(p.getInputStream()));
>
> int pid = Integer.parseInt(br.readLine());
>
> System.out.println(pid);
>
> p.destroy();
> p = null;
> br = null;
> }
> catch (java.io.IOException e)
> {
> System.out.println(e);
> }
> ===
>
> method 4:
> ===
> // Pid.java
> class Pid {
> static { System.loadLibrary("Pid"); }
> public native int getPid();
>
> public static void main(String args[])
> {
> Pid z = new Pid();
> System.out.println(z.getPid());
> z = null;
> }
> }
>
> // Pid.c
> #include "Pid.h"
> #include "unistd.h"
> JNIEXPORT jint JNICALL Java_Pid_getPid(JNIEnv *env, jobject obj)
> { return getpid(); }
> ===
>
> javac Pid.java
> javah Pid
> gcc -I/usr/lib/j2se/1.3/include -I/usr/lib/j2se/1.3/include/linux --shared -o libPid.so Pid.c
>
> export LD_LIBRARY_PATH=`pwd`
> ls -l libPid.so
> -rwxr-xr-x 1 msimons msimons 5111 Jan 22 22:23 libPid.so
>
> This method requires a c stub be compiled for each platform to be
> supported and requires the runtime library to be in the library search
> path. While it is certainly faster runtime than a perl or fork/exec
> method above they both royally suck...
> _______________________________________________
> vox-tech mailing list
> vox-tech@lists.lugod.org
> http://lists.lugod.org/mailman/listinfo/vox-tech
>
--
Mark K. Kim
http://www.cbreak.org/
PGP key available upon request.