This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 147664 - 'wait=yes' parameter in /etc/xinetd.d/* files doesn't work for non-INTERNAL services
'wait=yes' parameter in /etc/xinetd.d/* files doesn't work for non-INTERNAL s...
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: xinetd (Show other bugs)
3
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: Jay Fenlason
Brock Organ
http://cs.ozerki.net/zap/xinetd-bug/
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-02-10 02:06 EST by Andrew Zabolotny
Modified: 2014-08-31 19:27 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-03-22 13:48:07 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Andrew Zabolotny 2005-02-10 02:06:00 EST
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 13:36:13 EST
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.