Discussion:
using cygwin inetd to start a script on a server to run a java application
annie s
2014-06-05 16:22:36 UTC
Permalink
Hi, I am following the oracle doc

http://docs.oracle.com/javase/7/docs/technotes/guides/rmi/inetd/launch-service.html
(solaris specific)

I have two windows 2012 server VMs (firewalls off). I believe that I
have configured cygwin inetd correctly by following the directions in

C:\cygwin64\usr\share\doc\Cygwin\inetutils-server.README, running
/usr/bin/iu-config using values ntsec and creating user cyg_server on
the server. I start and stop inetd using cygrunsrv -S inetd and
cygrunsrv -E inetd. I have cygwin inetd ftp working on the machines.

What I am trying to do is to get the client to call an inetd service
on the server which in turn runs a script on the server which sets up
the environment and calls a java class called "Server".

My C:\cygwin64\etc\inetd.config on the server

ftp stream tcp nowait annie /usr/sbin/ftpd ftpd
example-server stream tcp wait cyg_server
/nms/bin/test/test test

c:\windows\system32\drivers\etc\services on the server

example-server 9999/tcp

i think the hosts file on both the server and the client is corrently
configured because ftp between the client and the server works

the test script on the client sets up the environment and then calls
/cygdrive/c/Apps/Java/jdk1.7.0_51/bin/java
-Djava.net.preferIPv4Stack=true -Djava.net.preferIPv4Addresses=true
-classpath c:\\cygwin64\\nms\\bin jmini.nms.console.inetd.Server 9999
&> /tmp/tmp.dat

Using Process Explorer I can see the client calling the cygwin inetd
service, and a java exe being created. The Server code is called but
the client timesout.

tmp.dat on the server contains

proxy Proxy[ServiceInterface,RemoteObjectInvocationHandler[UnicastRef
[liveRef: [endpoint:[192.168.100.10:57036](local),objID:[27e13e26:14662d7e06e:-7fff,
-976951803438894493]]]]]
server: failed to initialize registry proxy
Proxy[ServiceInterface,RemoteObjectInvocationHandler[UnicastRef
[liveRef: [endpoint:[192.168.100.10:57036](local),objID:[27e13e26:14662d7e06e:-7fff,
-976951803438894493]]]]] on port 9999
Exception java.net.BindException: Address already in use: JVM_Bind

Looking at TCP view on start up there are two inetd processes, the ftp
process (port 21) and the example-server (port 9999) process. when i
start the client there are three inetd processes, the ftp process
(port 21), the example-server (port 9999) process remote address the
server, and the example-server (port 9999) process remote address the
client. the java process starts on a port that is not shared with any
other process.

and the client dies with a java.rmi.ConnectIOException: error during
JRMP connection establishment; nested exception is:
java.net.SocketTimeoutException: Read timed out

My questions are can you see how I have misconfigured this? Have you
got a cygwin inetd process running a script/ java process and could
you share the secret sauce with me?

Thank you in advance

Annie
Eliot Moss
2014-06-06 19:05:42 UTC
Permalink
Dear Annie -- Again, I am not a deep expert, but the TCPView output
looks to be what I would expect if the inetd forks a copy of itself
to handle a new client connection. A TCP connection (as you probably
know) is distinguished by *both* the local host/port pair *and*
the remote host/port pair. So a local port can certainly be used
in multiple connections. It will, however, be a different socket
within the server.

I notice that the Java process is also listening, but on a different
local port. I am guessing that that is for the intended RMI connection.

That is, the point of the example-server port is to give the ability
to spawn Java jobs. They then listen on their own port to establish
an RMI connection. I presume that either the spawned inetd or the
spawned Java somehow communicates back to the remote client the port
number for the RMI protocol, namely 57088, so that the remote client
can connect to the listening Java instance.

I think maybe your issue has to do with wait/nowait in the inetd.conf
entry. One setting causes inetd itself to accept the connection, the
other causes the spawned server process to do it. Which way it should
work depends on the server process. The two ways are:

1) wait: spawn only ONE server process and it handles all bind requests;
inetd starts it only if a new request comes and the server process
is not already running. This is the normal case for udp/datagram
types of services.

2) nowait: spawn a server process for each request; inetd handles the
bind. This is normal for tcp.

So, if for RMI the model is ONE server process that then handles all
RMI requests for that host, even though the request may be for a tcp
connection, wait would be correct. That is what this page seems to
indicate:

http://docs.oracle.com/javase/7/docs/technotes/guides/rmi/inetd/launch-service.html#2

I see that you wrote nowait. I suggest changing it to wait. I am copying
this reply to the cygwin list for the archives.

Regards -- Eliot Moss
annie s
2014-06-09 14:41:29 UTC
Permalink
Hi Eliot, I really appreciate your time looking at this...

"
ftp stream tcp nowait annie /usr/sbin/ftpd ftpd
example-server stream tcp wait cyg_server
/nms/bin/test/test test
"

fyi example server is set to wait (and ftp is set to nowait)

i apologize if that was confusing.

has anyone any other suggestions?

thank you again

annie
Eliot Moss
2014-06-09 14:48:36 UTC
Permalink
Post by annie s
Hi Eliot, I really appreciate your time looking at this...
"
ftp stream tcp nowait annie /usr/sbin/ftpd ftpd
example-server stream tcp wait cyg_server
/nms/bin/test/test test
"
fyi example server is set to wait (and ftp is set to nowait)
i apologize if that was confusing.
has anyone any other suggestions?
So here's a wondering, broadening the strategy for addressing
your real desire, which is to have a Java server program spawned
automatically.

Oracle must have developed a preferred way for doing this on
Windows systems. The 'java' program (the Java Virtual Machine)
is a native Windows program. Why not use the native Windows
way of doing this, whatever it is?

Regards -- Eliot

Loading...