From Bugzilla Helper: User-Agent: Mozilla/5.0 Galeon/1.2.6 (X11; Linux i686; U;) Gecko/20020830 Description of problem: the security-fixed xinetd-2.3.9-0.72 suddenly insists that services are to be declared in /etc/services. This defeats the nice way of adding things to xinetd by simply dropping a file into /etc/xinetd.d/, and requires to touch a shared file through scripts again. Yuck. Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: 1. create a new service in /etc/xinetd.d/dummy service dummy { port = 6101 socket_type = stream protocol = tcp wait = no user = nobody server = /bin/cat } 2. service xinetd restart 3. telnet localhost 6101 Actual Results: telnet says: Trying 127.0.0.1... telnet: connect to address 127.0.0.1: Connection refused in /var/log/messages: Oct 24 15:07:12 xxxx xinetd[31337]: service/protocol combination not in /etc/services: dummy/tcp Oct 24 15:07:12 xxxx xinetd[31337]: xinetd Version 2.3.9 started with libwrap options compiled in. Expected Results: telnet localhost 6101 Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. <type>foo foo Additional info: We really liked the fact that xinetd will take new services straight out of the rpm, without any messing around in /etc/inetd.conf or /etc/services. And now that we have conviced people to deploy using RPMs, all of a sudden this breaks on installed systems. Please consider fixing ASAP.
Well, the new errata is 2.3.7-based (for other reasons), which may solve this for you.
Newer versions of xinetd require type = UNLISTED in any services that aren't listed in /etc/services. I've just confirmed that 2.3.10 works as expected once you include that line in your dummy service description.