waitFor and return (very strange)

[depo]

hi,
i've got this scenario

I have a java gui that launch external application (a dos script if
running on NT and a shell script if running on HP to launch a tcl
GUI).
To launch these scripts I use Process mechanism and wait using its
waitFor method.
These scripts (with right parameters) can launch a tcl gui in local or
remote (with rsh call) and return when i close tcl gui (so waitFor
returns)

It seems all ok but the strange behaviour is:


java GUI on HPa --> script ---> tcl GUI on HPa OK
java GUI on HPa --> script ---> tcl GUI on HPb OK
java GUI on NTa --> script ---> tcl GUI on NTa OK

but
java GUI on NTa --> script ---> tcl GUI on HPa not OK cause after
some minutes (with tcl gui running) waitFor returns (strange)
If i start the script (launched by java) from command line it doesn't
returns correctly (when tcl Gui on HPa is running)


All valid scenario seems to exclude errors on java code end error in
scripts
Can yu help me?
Thanks

 

[depo]

I want to explain that I start my bat script with
process.exec("CMD /C mybat.bat")
process.waitFor();




mybat.bat :
................
................
.................
rsh 172.16.241.97 -l bmsadmin "/opt/bms/STLS/unixcommands/srv_start
...."


I noticed that when scenario is NT and mybat.bat start rsh to launch
tcl gui in HPa=172.16.241.97 after few minutes rsh returns, mybat.bat
terminates and process.waitFor() exit with exitValue()=0 (but remote
tcl GUI still alive).
If i start mybat.bat via commandline never returns before stopping
remote tcl GUI

Thanks

hi,
i've got this scenario

I have a java gui that launch external application (a dos script if
running on NT and a shell script if running on HP to launch a tcl
GUI).
To launch these scripts I use Process mechanism and wait using its
waitFor method.
These scripts (with right parameters) can launch a tcl gui in local or
remote (with rsh call) and return when i close tcl gui (so waitFor
returns)

......

 

[Roedy Green]

process.exec("CMD /C mybat.bat")

what happen if you try

process.exec("CMD.exe /C call mybat.bat")

 

[depo]

what happen if you try

process.exec("CMD.exe /C call mybat.bat")

i obtain the same behaviour: after few minutes waitFor returns and i
don't understand why (the remote gui is still running).
As i said before if i start mybat.bat from command line it doesn't
return id tcl remote Gui is running (rsh doesn't return)
It seems like JVM close mybat process from its own.

i post my code for exec:

try
{
proc = Runtime.getRuntime().exec("CMD /C mybat.bat");
proc.getOutputStream().close();
outThread = new IOReader(proc.getInputStream());
errThread = new IOReader(proc.getErrorStream());
outThread.setPriority(1);
errThread.setPriority(1);
outThread.start();
errThread.start();
proc.waitFor(); //wait until run gui is terminated
}
catch(Throwable _ex)
{
System.out.println("Could not launch
"+command+"\n"+_ex.getMessage());
_ex.printStackTrace();
}

and for reader class

private class IOReader extends Thread
{
private BufferedInputStream bis;

protected IOReader(InputStream is)
{
bis = new BufferedInputStream(is);
}

public void run()
{
try
{
for(; bis.read() != -1; Thread.yield());
}
catch(IOException _ex) { }
finally
{
try
{
bis.close();
}
catch(IOException _ex) { }
}
}


}

Substituting waitFor with a sleep and a test about proc.exitValue()
(that could provoke an Exception if subprocess is not terminated)
doesn't solve cause exitValue() returns 0.



thanks

 

[Gordon Beaton]

i obtain the same behaviour: after few minutes waitFor returns and i
don't understand why (the remote gui is still running). As i said
before if i start mybat.bat from command line it doesn't return id
tcl remote Gui is running (rsh doesn't return) It seems like JVM
close mybat process from its own.

[...]

1. Don't do this until *after* waitFor() returns:

proc.getOutputStream().close();

2. I think you need to look at the behaviour of the rsh client or
server, or the application at the far end. When you do this from
the command line you create a slightly different environment for
the remote process. Among other things, isatty() is true, which
isn't the case when run it from Java. There may be flags you can
provide to tell rsh, rshd or the remote application to ignore this
difference. Does the remote write any text to the console when you
run it manually?

Just some ideas.

/gordon

 

[Guest]

rsh 172.16.241.97 -l bmsadmin "/opt/bms/STLS/unixcommands/srv_start..."
Try:

rsh 172.16.241.97 -n -l bmsadmin "/opt/bms/STLS/unixcommands/srv_start..."

- Dario

 

[Roedy Green]

i obtain the same behaviour: after few minutes waitFor returns and i
don't understand why (the remote gui is still running).
As i said before if i start mybat.bat from command line it doesn't
return id tcl remote Gui is running (rsh doesn't return)
It seems like JVM close mybat process from its own.

try using the batch START command with wait/nowait options.

 

[depo]

2. I think you need to look at the behaviour of the rsh client or
server, or the application at the far end. When you do this from
the command line you create a slightly different environment for
the remote process. Among other things, isatty() is true, which
isn't the case when run it frcom Java. There may be flags you can
provide to tell rsh, rshd or the remote application to ignore this
difference. Does the remote write any text to the console when you
run it manually?

Just some ideas.

/gordon

I don't find difference in env variables (printed by set command) when
rsh started by command line or java.Must i set an hide variable?

But when rsh is started by command line i see 3 lines (and all is ok
rsh doesn't return if remote gui is running)

access control disabled from any host
ttytype=couldn't open /dev/tty for reading
stty : Unknown error

In java code input stream proc.getInputStream() and
proc.getErrorStream() print nothing and rsh returns after few minutes


Using as Dario said
rsh 172.16.241.97 -n -l bmsadmin
"/opt/bms/STLS/unixcommands/srv_start..."
provokes command line returns as in java case

thanks

 

[depo]

2. I think you need to look at the behaviour of the rsh client or
server, or the application at the far end. When you do this from
the command line you create a slightly different environment for
the remote process. Among other things, isatty() is true, which
isn't the case when run it frcom Java. There may be flags you can
provide to tell rsh, rshd or the remote application to ignore this
difference. Does the remote write any text to the console when you
run it manually?

Just some ideas.

/gordon

I don't find difference in env variables (printed by set command) when
rsh started by command line or java.Must i set an hide variable?

But when rsh is started by command line i see 3 lines (and all is ok
rsh doesn't return if remote gui is running)

access control disabled from any host
ttytype=couldn't open /dev/tty for reading
stty : Unknown error

In java code input stream proc.getInputStream() and
proc.getErrorStream() print nothing and rsh returns after few minutes


Using as Dario said
rsh 172.16.241.97 -n -l bmsadmin
"/opt/bms/STLS/unixcommands/srv_start..."
provokes command line returns as in java case

thanks

 

[Gordon Beaton]

I don't find difference in env variables (printed by set command) when
rsh started by command line or java.Must i set an hide variable?

I was not referring to environment *variables*. The runtime
environment itself is slightly different when you run from an
interactive or non-interactive shell, because the situations are
treated differently by the remote shell.

But when rsh is started by command line i see 3 lines (and all is ok
rsh doesn't return if remote gui is running)

access control disabled from any host
ttytype=couldn't open /dev/tty for reading
stty : Unknown error

In java code input stream proc.getInputStream() and
proc.getErrorStream() print nothing and rsh returns after few
minutes

These messages appear to come from the shell initialization on the
remote host (.bashrc, .bash_profile, .tcshrc or similar). If you don't
see these lines when you use rsh from java, it means that there is a
difference in the way the remote login shell handles the
non-interactive case. There may also be some conditional expressions
in the login scripts on the remote host.

These are all Unix issues that have nothing to do with Java. Read the
man pages for the remote shell, paying particular attention to
concepts like login, non-login, interactive and non-interactive
shells. Ask further questions in an appropriate unix shell newsgroup.

Using as Dario said
rsh 172.16.241.97 -n -l bmsadmin
"/opt/bms/STLS/unixcommands/srv_start..."
provokes command line returns as in java case

Did you try my first suggestion, to leave the OutputStream open?

/gordon

 

[depo]

Did you try my first suggestion, to leave the OutputStream open?

/gordon

I thought to have tried your suggest but i forgot a close in my code.
Leaving OutputStream open solves the problem, thank you very much, but
can you explain me why?
Can i close that stream after waitFor?
I remember in previuos java version (< 1.4) it was suggest to close
OutputStream not used....but i don't remember why...

In any case THANKS YOU VERY MUCH INDEED

 

[Gordon Beaton]

I thought to have tried your suggest but i forgot a close in my
code. Leaving OutputStream open solves the problem, thank you very
much, but can you explain me why?

In that case, I would expect rsh -n as suggested by Dario to work too.
Read the man page.

I haven't looked particularly closely at how rsh works, but I believe
that it forks into two processes, one to handle traffic in each
direction. When you close the OutputStream, the rsh client handling
"forward" traffic gets EOF on its stdin and terminates locally, while
the other process continues to handle traffic coming back from the
remote application. Java only knows about one of these processes and
waitFor() detects when it terminates, regardless of the other one.

Can i close that stream after waitFor?

Yes. You should close all three of the streams after waitFor().

/gordon