Bug 124740 - xinetd can't start up server after server dies
xinetd can't start up server after server dies
Status: CLOSED NOTABUG
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: xinetd (Show other bugs)
3.0
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Jay Fenlason
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-05-28 19:54 EDT by Linda Lee
Modified: 2014-08-31 19:26 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-06-24 23:16:06 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
server (16.33 KB, text/plain)
2004-05-28 19:55 EDT, Linda Lee
no flags Details
client (13.42 KB, text/plain)
2004-05-28 19:55 EDT, Linda Lee
no flags Details
Tar file contains sources for client/server. (80.00 KB, text/plain)
2004-06-02 13:20 EDT, Linda Lee
no flags Details

  None (edit)
Description Linda Lee 2004-05-28 19:54:11 EDT
Description of problem:


Version-Release number of selected component (if applicable):

RHAS 3 FCS is installed on intel platform, with new xinetd patch from
bug fix 123522 (xinetd-2.3.12-6.3E).

Linux test1 2.4.21-4.ELsmp #1 SMP Fri Oct 3 17:52:56 EDT 2003 i686
i686 i386 GNU/Linux


Configured a rpc service in /etc/xinetd.d.

# default: on
service toto_server
{
        disable = no
        type = RPC 
        socket_type = stream 
        wait = no
        protocol = tcp
        rpc_version = 1
        rpc_number = 100145
        user = root
        server = /etc/init.d/in.toto_server
}

Ran the client program and it got timed out for the first run but it
was OK for the subsequence runs.  I noticed that the server stays
forever and  does not go away, as the behaviour of inetd on Solaris. 
Another thing is that if manually killed the server and ran the client
program again, the xinetd could not start the server.  We need to
either reboot the machine or restart the xinetd, which also is NOT the
same behaviour as inetd.


How reproducible:


Steps to Reproduce:

1. add toto_server config file in /etc/xinetd.d
2. cp in.toto_server to /etc/init.d/
3. add a line "toto_server     100145" to /etc/rpc.
4. service xinetd restart
5. ran client program (got timed out).
6. ran client program (ok this time)
7. manually kill toto_server
8. ran client program and it failed as toto_server is not UP.


  
Actual results:

Can't ran client program.

Expected results:

Could run client program even after the server dies.  Also, the first
time client program should not time out.

Additional info:
Comment 1 Linda Lee 2004-05-28 19:55:07 EDT
Created attachment 100690 [details]
server
Comment 2 Linda Lee 2004-05-28 19:55:35 EDT
Created attachment 100691 [details]
client
Comment 3 Bastien Nocera 2004-06-02 05:49:10 EDT
Linda, could you upload the source files of the server and client, in
place of the binaries you uploaded now?
Comment 4 Linda Lee 2004-06-02 13:20:58 EDT
Created attachment 100798 [details]
Tar file contains sources for client/server.

Do "tar xvf toto.tar" to retrieve files.
Comment 5 Linda Lee 2004-06-02 13:22:29 EDT
I have attached sources in the attachment.  To begin with, I did
"rpcgen -a toto.x".
Comment 6 Jay Fenlason 2004-06-03 14:27:19 EDT
What happens if you change "wait = no" to "wait = yes" in the toto
server config?  My test servers, which use "wait = yes" do not show
this problem.
Comment 7 Linda Lee 2004-06-03 14:45:12 EDT
I changed "wait = yes" in the toto_server config file and the result
is the same as "wait = no".  The first time I ran toto_client and got
"call failed: RPC: Timed out". The toto_client call was successful in
the subsequent runs.  Then, pkill toto_server and ran the client
again. And, I got "RPC: Remote system error - Connection refused" and
I didn't see the toto_server was up.

BTW, did you get "RPC: Timed out" at the first run for your test
server?

You could also test my toto_server and toto_client as they are in the
attachment.  I don't know why yours works for "wait = yes" but not
mine.  Thanks!!

Comment 8 Linda Lee 2004-06-07 19:08:21 EDT
I tested the "wait = yes" again for toto_server/toto_client.  It
worked now.  The scenarios that I tested are like:

1. The first client request still got TIMED OUT (it is still a bug).
2. The subsequent client requests are OK.
3. Then, pkill toto_server, do the "ps" and found out that toto_server   
   is automatically started.
4. Now, even the first and subsequent client requests are OK.

According to the man page of xinetd.conf, the "wait" should set to no
for multithreaded tcp rpc service.  Apparently, it does not behave
that way.

Note:  also tested with xinetd-2.3.12-6.3E patch.

Comment 10 Jay Fenlason 2004-06-24 23:16:06 EDT
I suspect this bug has the same cause as #125485.  If the rpc server 
misbehaves, and registers itself with portmap (overwriting xinetd's 
registration), after the server exits, xinetd is unaware that it's 
registration with portmap hsa been overwritten, and no client 
requests will ever be sent to it.  Since no client request is sent 
to xinetd, it does not restart the server. 
 
(Actually, what I see is that the original client request (the one 
that timed out) is never read (because the toto_server opened its 
own socket), so xinetd sees the unread request and immediately 
starts a new toto_server when the initial one is killed.  The second 
toto_server also ignores the original request. . .  Etc. 
 
Reopen this bug if you can replicate it with an rpc server that was 
correctly written to be called from xinetd. 

Note You need to log in before you can comment on or make changes to this bug.