Launch Background Unix Processes
Hello Hackers,
Do you feel smart today ? Need a Brain Teaser to help you feel like God ?
Well, then here is a brain teaser for you.
CAVEAT/DISCLAIMER: The answer to this teaser might be something very simple, something obvious that I am missing. In which case, you may not feel like God, but rest assured, I will indeed feel like an Idiot, even if it is for just a few moments. I think my fragile ego has a reasonable amount of padding and armor now.
I am trying to launch a shell script from a Java program, which in Java vernacular translates to an executable jar, right ?
BTW, I am using Fedora Core 3 Linux with 2.6.current kernel and JVM 1.5.0_09.
Anyway, what I need out of it, is for the script to continue running even after the Java thread as well as the virtual machine have terminated. Under the current circumstances, the launched process exits as soon as the thread terminates. Here is the source code for the function that I use to do this.
protectedint shellExecuteBackground ( String argCommand )
{
// this one adds the 'nohup' in the beginning and '&' in the end to
// ensure process continues to run. the caller is requested not to
// add those values
int retVal = -0xFFFF;
try
{
Runtime runTime =null;
Process process =null;
String command;
command ="nohup " + argCommand;
if ( !command.trim ().endsWith ("&" ) )
{
command +=" &";
}
runTime = Runtime.getRuntime ();
process = runTime.exec ( command );
retVal = 0;
}
catch ( Exception e )
{
log.error ("Could not launch command " + argCommand +"in background." );
log.debug ("Exception details - ",
e );
if ( retVal >= 0 )
{
retVal = -0xFFFF;
}
}
return retVal;
}
As you notice, the function seems simple enough. The string 'argCommand' has the path to the shell script. I have tried with the variation of 'sh -c' etc.
NOTE: I also need to be able to terminate the process afterwards, so the name of the shell script needs to show up when I do 'ps ax | grep $argCommand'. Also, we need to use Java due to the fact that the remaining code in the program that does this requires some features unique to Java. I have also posted this on a news group or two. So, let's see what happens.
So, if you have done something similar, now is the time to shine.
TIA
> Do you feel smart today ? Need a Brain Teaser to help
> you feel like God ?
Please stop trying to manipulate us.
> I am trying to launch a shell script from a Java
> program, which in Java vernacular translates to an
> executable jar, right ?
No. And it's not clear why you even brought that up, since you don't use executable jars anywhere in your example.
> Under the
> current circumstances, the launched process exits as
> soon as the thread terminates.
Maybe it's supposed to. What is the launched process?
> // this one adds the 'nohup' in the beginning and '&' in the end to
> // ensure process continues to run.
The & is interpreted by the shell. When you call exec(), the shell is not invoked.
Unless nohup knows what to do with it (the man page didn't mention it) I'd expect the & to confuse nohup.
> As you notice, the function seems simple enough. The
> string 'argCommand' has the path to the shell script.
> I have tried with the variation of 'sh -c' etc.
I'm guessing you didn't use "sh -c" right.
> we need to use Java due to the fact that the
> remaining code in the program that does this requires
> some features unique to Java.
What features?
Personally, I'd be wary of a system with largely unlike components invoking each other like this.
Another approach could be to have a startup shell script that starts the background process, and then starts the Java process. Could be a bit cleaner.
> So, if you have done something similar, now is the
> time to shine.
Please stop that.
All right, no more manipulation.
Here is some additional information.
1. The controlling process is an executable jar run from a JVM.
2. The launched process is yet another executable jar launched from within a shell script, so from the perspective of launcher application, it has to launch a shell script.
3. I have already tested the part about 'nohup' and '&' directly from the shell and the '&' at the end helps. There is some documentation that I came across while doing the initial research where there is a consensus about using the '&' with the 'nohup'. I can unfortunately not provide the hyperlinks at this moment because I'll have to wade through a few hundred search engine results all over.
4. 'sh -c' - I tried that and it does not seem to make any diference.
5. Unique Java Features - the controlling process needs to communicate with a remote web-service using SOAP.
6. Being wary of system like this, while sensible, sometimes needs to be done. I was hoping to get some peer assistance without writing a blog of my life's story ;)
7. Mother of all shell script that glues all this together seems to be a sensible solution to me too, but I trying to see if there are alternatives.
> 3. I have already tested the part about 'nohup' and
> '&' directly from the shell and the '&' at the end
> helps. There is some documentation that I came
> across while doing the initial research where there
> is a consensus about using the '&' with the 'nohup'.
Yes but that's from the shell. When you use Runtime.exec you're not using the shell.
> . 'sh -c' - I tried that and it does not seem to make
> any diference.
You may have used it the wrong way.
> 5. Unique Java Features - the controlling process
> needs to communicate with a remote web-service using
> SOAP.
That's not unique to Java.
Just out of curiosity, why are you spawning new Java processes? Why not just run the Java code in new threads?
