Red Hat Bugzilla – Bug 124740
xinetd can't start up server after server dies
Last modified: 2014-08-31 19:26:16 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
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.
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.
Can't ran client program.
Could run client program even after the server dies. Also, the first
time client program should not time out.
Created attachment 100690 [details]
Created attachment 100691 [details]
Linda, could you upload the source files of the server and client, in
place of the binaries you uploaded now?
Created attachment 100798 [details]
Tar file contains sources for client/server.
Do "tar xvf toto.tar" to retrieve files.
I have attached sources in the attachment. To begin with, I did
"rpcgen -a toto.x".
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
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
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
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
Note: also tested with xinetd-2.3.12-6.3E patch.
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.