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