Bug 147664 - 'wait=yes' parameter in /etc/xinetd.d/* files doesn't work for non-INTERNAL services
Summary: 'wait=yes' parameter in /etc/xinetd.d/* files doesn't work for non-INTERNAL s...
Alias: None
Product: Fedora
Classification: Fedora
Component: xinetd   
(Show other bugs)
Version: 3
Hardware: x86_64
OS: Linux
Target Milestone: ---
Assignee: Jay Fenlason
QA Contact: Brock Organ
URL: http://cs.ozerki.net/zap/xinetd-bug/
Depends On:
TreeView+ depends on / blocked
Reported: 2005-02-10 07:06 UTC by Andrew Zabolotny
Modified: 2014-08-31 23:27 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-03-22 18:48:07 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

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:

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):

How reproducible:

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 

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.

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