Bug 147664

Summary: 'wait=yes' parameter in /etc/xinetd.d/* files doesn't work for non-INTERNAL services
Product: [Fedora] Fedora Reporter: Andrew Zabolotny <anpaza>
Component: xinetdAssignee: Jay Fenlason <fenlason>
Status: CLOSED NOTABUG QA Contact: Brock Organ <borgan>
Severity: medium Docs Contact:
Priority: medium    
Version: 3CC: jfeeney, linux_4ever
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
URL: http://cs.ozerki.net/zap/xinetd-bug/
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2005-03-22 18:48:07 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Andrew Zabolotny 2005-02-10 07:06:00 UTC 
From Bugzilla Helper:
User-Agent: Opera/7.51 (X11; Linux i686; U)  [en]

Description of problem:
If you use 'wait = yes' in a configuration file for a particular 
inetd service, and the service is not internal to xinetd, it doesn't 
work. The stdin/stdout handles for the launched process don't work, 
although if you set the 'server' parameter to point to a script that 
looks like this:

#!/bin/sh
ls -la /proc/self/fd/ >/tmp/log
echo "Hello"

and then try to connect via, say, telnet to given port, you won't see 
the "Hello" (if wait=yes), although the /tmp/log file will list 
correctly stdin and stderr as bound to the correct socket. In fact, 
as soon as 'echo' is started, the process seems to be terminated by 
SIGPIPE, because any commands after the 'echo' won't execute.


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

How reproducible:
Always

Steps to Reproduce:
1. Get the following files from the listed above URL:
   - testservice (xinetd service description file)
   - test_service (the script that is run by the service)
   - test.log (the log file genetated by test_service)
   - messages (the contents of the syslog)
2. Put testservice in /etc/xinetd.d
3. Put test_service in /sbin and chmod a+x it
4. service xinetd restart
5. telnet localhost 40000


Actual Results:  xinetd seems caught in a loop, and disables service 
due to service respawning 'too fast'


Expected Results:  Expecting the text 'Hello, world' to come out of 
telnet.


Additional info:
Comment 1 Steve Grubb 2005-03-22 18:36:13 UTC 
I'm the upstream maintainer of Xinetd. A wait service is one that accepts the
connection. telnet does not accept the connection - it expects the connection to
be accepted and the socket dup'ed to the stdin/out descriptors.

There is also no way for xinetd to check to see if a child has accepted the
connection. Therefore, when you have a program that's configured as a wait
service and it doesn't accept the connection, the socket is still readable when
xinetd goes back to the select loop. Around and around it goes.

This bug report can be closed - not a bug.