This looks weird... don't you have an /etc/services? Is this by any chance the
Japanese version, or is it the English one?

I tracked down the problem. I'm not sure whether it is a bug or not.
xinetd was failing when it called getservbyname with a NULL pointer for 
the protocol (see test program below. The null pointers all failed).
The problem was with /etc/nsswitch.conf which hadn't been updated 
by the glibc package. I deleted this file and reinstalled it from glibc 
and xinetd runs and starts. 

However there is still something strange going on which I can't track down. I
run four linux boxes:  2 i386 boxes with REdhat 7.0 (xinetd), one alpha with
Redhat 6.2 and one i386 box with Japanese Redhat 7.0.
When using rsh from the 7.0J machine to the 7.0E machines it takes around 1
minute to complete. rsh from any other machine to any other machine is
instantaneous. If I remove xinetd and install inet then it is instanteous.
(authentication is done using hosts.equiv and all machines are using NIS by
ypbind). I have now idea how to debug this problem. Starting xinted with th
debug flag shows nothing different. 


/* gcc check_getservbyname*/
int main(){
    char *s[20];
    char *p[20];
    struct servent *x;
    int n,i;
    s[0]="echo";   p[0]=CHAR_NULL;
    s[1]="echo";   p[1]="tcp";
    s[2]="ftp";    p[2]=CHAR_NULL;
    s[3]="ftp";    p[3]="tcp";
    s[4]="telnet"; p[4]=CHAR_NULL;
    s[5]="telnet"; p[5]="tcp";
    s[6]="finger"; p[6]=CHAR_NULL;
    s[7]="finger"; p[7]="tcp";
    s[8]="login";  p[8]=CHAR_NULL;
    s[9]="login";  p[9]="tcp";
    s[10]="shell";  p[10]=CHAR_NULL;
    s[11]="shell";  p[11]="tcp";
    n=12;
    for(i=0;i<n;i++){
	x=getservbyname(s[i],p[i]);
	if (x==NULL) printf("service :%s, protocol %s failed\n",s[i],p[i]);
	else         printf("service :%s, protocol %s succeeded\n",s[i],p[i]);
    }
}    

The first sounds like a problem in glibc... Ccing jakub. You can get around
using getservbyname by specifying a port number, but that shouldn't be necesarry.

As for the other problem, I'm guessing at problems doing a reverse dns lookup on
the machine you're connecting to of the machine you're connecting from.

Could you check to see if reverse DNS is a problem.

How do I check Reverse DNS?

Try to resolve the host you connected from on the server...

If you connected from host "foo" to host "bar", try doing "host foo" on "bar"

SI've installed nscd and this has eliminated the problem.

OK, that should make DNS (and other) lookups faster by caching the results...
the remaining part, why glibc couldn't look up service names, is a glibc problem
so I'll reassign it.

I've installed most of rawhide and the xinetd problem has freturned in a
slightly different form. Xinetd refues to start
[root@mudack xinetd-2.1.8.9pre11]# /usr/sbin/xinetd -d
01/1/12@02:27:09: WARNING: {parse_value_list} Bad log-on_failure flag: PID
[line=11]
01/1/12@02:27:09: DEBUG: {handle_includedir} Reading included configuration
file: /etc/xinetd.d/chargen [line=14]
01/1/12@02:27:10: DEBUG: {handle_includedir} Reading included configuration
file: /etc/xinetd.d/chargen-udp [line=14]
01/1/12@02:27:10: DEBUG: {handle_includedir} Reading included configuration
file: /etc/xinetd.d/daytime [line=15]
01/1/12@02:27:10: DEBUG: {handle_includedir} Reading included configuration
file: /etc/xinetd.d/daytime-udp [line=14]
01/1/12@02:27:10: DEBUG: {handle_includedir} Reading included configuration
file: /etc/xinetd.d/echo [line=15]
01/1/12@02:27:10: DEBUG: {handle_includedir} Reading included configuration
file: /etc/xinetd.d/echo-udp [line=14]
01/1/12@02:27:10: DEBUG: {handle_includedir} Reading included configuration
file: /etc/xinetd.d/finger [line=15]
01/1/12@02:27:10: DEBUG: {handle_includedir} Reading included configuration
file: /etc/xinetd.d/linuxconf-web [line=12]
01/1/12@02:27:10: DEBUG: {handle_includedir} Reading included configuration
file: /etc/xinetd.d/ntalk [line=13]
01/1/12@02:27:10: DEBUG: {handle_includedir} Reading included configuration
file: /etc/xinetd.d/rexec [line=12]
01/1/12@02:27:10: DEBUG: {handle_includedir} Reading included configuration
file: /etc/xinetd.d/rlogin [line=14]
01/1/12@02:27:10: DEBUG: {handle_includedir} Reading included configuration
file: /etc/xinetd.d/rsh [line=14]
01/1/12@02:27:10: DEBUG: {handle_includedir} Reading included configuration
file: /etc/xinetd.d/rsync [line=15]
01/1/12@02:27:10: DEBUG: {handle_includedir} Reading included configuration
file: /etc/xinetd.d/swat [line=13]
01/1/12@02:27:10: DEBUG: {handle_includedir} Reading included configuration
file: /etc/xinetd.d/talk [line=15]
01/1/12@02:27:10: DEBUG: {handle_includedir} Reading included configuration
file: /etc/xinetd.d/telnet [line=12]
01/1/12@02:27:10: DEBUG: {handle_includedir} Reading included configuration
file: /etc/xinetd.d/tftp [line=14]
01/1/12@02:27:10: DEBUG: {handle_includedir} Reading included configuration
file: /etc/xinetd.d/time [line=16]
01/1/12@02:27:10: DEBUG: {handle_includedir} Reading included configuration
file: /etc/xinetd.d/time-udp [line=14]
01/1/12@02:27:10: DEBUG: {handle_includedir} Reading included configuration
file: /etc/xinetd.d/wu-ftpd [line=15]
Service defaults
	Instances = 60
	Logging to syslog. Facility = authpriv, level = info
	Log_on_success flags = HOST PID
	Log_on_failure flags = HOST

01/1/12@02:27:11: DEBUG: {cnf_start_services} mask_max = 0, services_started = 0
01/1/12@02:27:11: CRITICAL: {init_services} no services. Exiting...

I've checked /etc/services and /etc/nsswitch.conf and I've tried tracing through
the code but I haven't been able to figure out what is going wrong

I too ran into this problem, "Unknown service: telnet".  I too poked into the sources of 
xinetd to find the failed call to getservbyname().   And, wrote a similar test program.

One way of working around the problem is to add "protocol" lines into the trouble 
xinetd.d configurations (telnet, rlogin, rsh, and ftp in my case).

After reading this bug report, I was curious whether or not my NIS configuration could 
be faulty.  I moved "files" before "nisplus"; lo, my getservbyname test started finding 
default protocols.  Therefore, I have a problem with my NIS configuration.

I will fix my NIS configuration tomorrow.  Just wanted to share my experience in case 
someone else stumbles across this.

Lots of things changed in the NIS NSS support.
If you are able to reproduce problems with contemporary (FC2 or FC3t2+)
glibc, please file a new bug.