Bug 125485

Created attachment 100946 [details]
tar file for toto_server/toto_client

I have attached sources in the attachment.  To begin with, I did
"rpcgen -a toto.x".

Same attachment for bugId 124740.

Do "tar xvf toto.tar" to retrieve files.

The toto_server program was not written so that it could be called 
from xinetd.  Look at main(): at startup it does 
transp = svctcp_create(RPC_ANYSOCK, 0, 0); 
creating a new tcp listener socket.  It then registers the socket 
with 
if (!svc_register(transp, COUNTER, COUNTERVERS, counter_1, 
IPPROTO_TCP)) { 
This unregisters the service that xinetd had registered and 
registers itself instead. 
 
I'm attaching a tarball of my test programs (the jf and fj services) 
to this bug report.  Note that jf_svc.c's main is different.  It 
starts by doing 
        if (getsockname (0, (struct sockaddr *)&saddr, &asize) == 0) 
{ 
... 
} else { 
... 
transp = svctcp_create(sock, 0, 0); 
... 
if (!svc_register(transp, JF_PROG, JF_VERS, jf_prog_1, proto)) 
... 
} 
If it was started by xinetd, stdin (descriptor 0) is a socket, so 
the getsockname will succeed, and it will read the RPC information 
from stdin.  If stdin is not a socket, it was not started by xinetd, 
and it creates its own socket and registers it. 
 
 
 

Created attachment 101394 [details]
sample rpc test programs

I have re-compiled my toto.x using -I option and verified it works
ONLY for "wait=yes".  BUT, it DOES NOT work for "wait=no".  According
to the man page, "wait=no" is for multi-threaded rpc service and tcp
service expects the value to be "no".  Does RHAS 3 support
multi-threaded rpc service??

I also verified your sample rpc test program only works for
"wait=yes".  If I changed to "wait=no" and invoked r_jf on the remote
host, it complained:

RPC: Unable to receive; errno = Connection reset by peer

And the jf_svc is not up on the remote host. On the /var/log/messages
of the remote host, the error message appeared.

Jun 30 12:56:55 remote_host jf[4779]: cannot create tcp service.

Recall that to xinetd "multi-threaded" means "xinetd does the 
accept()", and "single-threaded" means "the server does the 
accept()".  I don't see any thing in the xinetd source code that 
would prevent multi-threaded rpc servers from working.  However, I 
don't see any support in glibc's sunrpc/ directory for a TCP RPC 
server where the super-server (xinetd) did the accept(), and passed 
the remote file descriptor as stdin.  So if there is a bug here, 
it's in glibc's sunrpc code.  I've changed the summary of the bug to 
more accuratly represent the problem, and I'm reassinging this to 
the glibc maintainer. 

What does everybody expect?  We are not doing any development of RPC.
 It is as it is.  We might fix bugs, but that's about it.  If there is
functionality missing, it remains this way.

If you want a better RPC implementation, use one of the separate
packages.  I don't thing RHEL3 contains in, but they exist.

You can probably hand-code some server which uses the RPC functions
and works th way you want.  But rpcgen as we have does not.

So, say explicitly what you think you need to be done (not a simple
"make this work", since as said, we will not extend RPC's
functionality).  If there is a little change in an interface or a very
small addition, we can talk about it.

What I would like is to fix this bug so that if "wait=no" is
specified, xinetd could start up the rpc server.  I don't expect you
to extend the RPC functionalities. (Of course, I would be very happy
to hear it if you do).  Thanks!

I'm closing this bug.  The RPC implementation we have is what it is.  Blame the
original RPC authors for it (incidently, Sun).  There is nothing we can do
without disturbing the existing code base and  users.