http://bugzilla.suse.com/show_bug.cgi?id=940357 http://bugzilla.suse.com/show_bug.cgi?id=940357#c2 --- Comment #2 from David Richards <drichard@largo.com> --- Understood completely, and I have more information. I think that this software is really absolutely broken and possibly should be considered for removal. I built an Ubuntu server to match our OpenSuse server and enabled RSH and now Ubuntu is doing the same thing. It works initially, but after a good while of may users hammering it with RSH requests, it hangs and stops accepting connections. Here is what else I found out in my testing: I ran xinetd in the foreground and when it fails, the RSH request is not even getting to xinetd at all. I enabled pam debugging for "rsh" and then touched pam_debug and was able to get logging information. When the requests are working, you can clearly see all of the interaction with pam. When it stops working, pam completely stops logging....these requests are not even getting anywhere near PAM. Ubuntu offers rsh-redone-server and I installed that package for testing and it did the same thing. When RSH stops accepting connections, rlogin and ssh continue to work. So it appears not be some kind of load or user threshold. I tried bumping up the limits.conf file to allow more maxusers and maxsysusers, neither of which helped. I tried kicking off some users when it stopped working, and it didn't allow more connections for a while, so that wasn't the issue. When it fails, rsh requests are being accepted from other servers, but not from one particular server. So it's almost like there might be a throttle or tuning parameter that is not exposed anywhere and we are just hitting the defaults. I considered looking at the source code itself. Previously this would be tuned in the old xinetd.d scripts for each service. So I really was at the end of the road with this thing, It's not xinetd nor pam that is causing this issue...but I don't see any tuning files beyond that. RSH is a child of xinetd, and it's just not getting that far. I moved our infrastructure over to SSH in this use case, because it's taking so long to get this working. If you want to explore resolving this as a back burner issue, I would be happy to help. But it might be time just to retire this package, it's really not working very well. -- You are receiving this mail because: You are on the CC list for the bug.