1/ Dont't forget if you call "rsh" without command it uses "rlogin".
It   means in this case you need to enabled "rlogin" in the
/etc/xinetd.d/rlogin too. For testing is good use something like:
"/usr/bin/rsh <host> ls".

2/ You need to add "rsh", "rlogin" to /etc/securetty too.

3/ Must be possible connect from server to client. The rsh/rlogin uses
reverse (stderr) connection. So there is two(!) connections,
client->server and server->client. Maybe you can try disable iptables
(service iptables stop) for your tests.

4/ Your server must be enable convert client IP to full client hostname.

5/ in the file ~/.rhosts is required full client hostname.

If you have still a problem connect to your server, please add to your
bugreport "strace" outputs:

Client: 
        $ strace -f -o client.trace /usr/bin/rsh <host>

Server (it's more dificult):

- create shell script:
     #!/bin/bash
     /usr/bin/strace -f -o /tmp/server.trace /usr/sbin/in.rshd

- add path to this script to /etc/xinetd.d/rsh (options server=)
- restart xinetd (service xinietd restart)
- check the file /tmp/server.trace on server after failed connection

Note: with strace on client you can have a permission problem as
non-root user.

None of ideas #1 through #5 would explain the intermittent nature
of the problem. When I say intermittent I really mean it. One
second it will work. A few seconds later it will fail. A few seconds
later it might work again. That's not a problem with my system
configuration.

I'm attaching two client-side strace output files. One shows a 
successful rlogin and the other a failure. In the successful case
you can see where it makes the connection, reads "exit\n" as I type
it in at the remote shell prompt, and the session is closed normally.

In the failure case you can see that the connection is initially
successful but at the point where the remote shell (bash) tries
to read a command from stdin it gets an ERESTARTSYS error code and
the session is terminated. This is wrong. It's as though the
ERESTARTSYS error code is being treated as a real error instead of
a request to restart the system call.

Created attachment 107819 [details]
Client-side strace of a successful rlogin

Created attachment 107820 [details]
Client-side strace of a failed rlogin.

Thanks for your strace outputs. You didn't use "-f", so in your strace
output missing client child process that read data from server (client
uses two processes).

Please, can you do it again and for server too. And --please-- use
"-f" option for strace :-) I don't see problem in your actual strace
output, but we don't know why client child process was exited.

ERESTARTSYS is only ptrace information about kernel internal stuff and
it doesn't return to userspace. It's no problem.

Please, check your server PAM setting. The "rlogin" use it and for
example pam_limits setting can disable login to server if there is
used all user's resources.

I am also having this problem. It did not appear to happen until 
after I updated all of the packages on the system. Booting into the 
stock kernel seems to solve the problem for now. I have used the same 
configuration successfully on a RH9 system. 

Thought I'd add that the error only happens once in a while, and I 
can't seem to tie it down to any particular happening. I executed the 
same command twice within seconds of each other and one failed and 
one was successful. I happened to be strace'ing the execution (as 
shown above with the -f) and will be attaching them.

Created attachment 108391 [details]
sucessful client side trace

Created attachment 108392 [details]
un-sucessful client side trace

Make, can you try server side (rlogind) strace too. I think client
side looks without problems.

By the way, "rsh" without command, calls "rlogin".

I'm currently strace'ing the rlogin as shown above and now the 
problem doesn't occur. Is there a possiblity of a timing issue that 
strace is taking care of. The reason that I mention this is that 
rlogin seems a little bit slower than when it isn't running through 
strace on the server. I've tried around 600 rlogins and haven't had a 
problem. Seems kinda wierd to me.

It looks like bug #137808 -- this bug isn't possible detect with
strace or gdb :-( The problem is somewhere around place where the
"login" tries initialize pseudo terminal.

Too bad some of us aren't authorized to see #137808.

So, has anyone found a solution for this?  I also am interested, and
am also unable to view #137808

Can anyone confirm this bug on actual FC4?

Closing due to lack of response.

FC3 is the responsibility of Fedora Legacy now, and this is not
a security issue.  (Indeed, using rlogin rather than ssh is more
of a security issue.)  If this occurs in FC4 or FC5, please reopen.