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