Bug 320281 - in.rlogind performance issues
in.rlogind performance issues
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: glibc (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2007-10-05 11:45 EDT by Chuck Mead
Modified: 2008-08-04 00:34 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-08-04 00:34:58 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Chuck Mead 2007-10-05 11:45:42 EDT
Description of problem: rsh connections take 30 to 45 seconds to connect

Version-Release number of selected component (if applicable): we've tested on
rhel3 u5 and rhel4 u5. the problem exists on both.

How reproducible: connect via rsh

Steps to Reproduce:
Actual results: connection takes as long as 45 seconds though the avg is 30.

Expected results:

Additional info:
Comment 1 Chuck Mead 2007-10-05 11:46:23 EDT
- If the client is listed first in hosts.equiv, rlogind continues to scan/check 
every entry in hosts.equiv even though a match has already been found.

- if 'files' is used in nsswitch.conf coupled with a large /etc/hosts file, 
then the entire files contects are read for every entry in /etc/hosts.equiv - 
this results in huge wait times on the read() syscall.
Comment 2 Adam Tkac 2008-01-10 05:35:03 EST
Reassigning to proper owner
Comment 3 Adam Tkac 2008-03-13 13:09:04 EDT
As far as I know glibc is responsible for parsing hosts file. Reassigning to
glibc for inspection
Comment 4 Ulrich Drepper 2008-08-04 00:34:58 EDT
There won't be any change to make this faster.

The claim that we do work beyond the point where we already know there is a match is not true.  It might appear so from the logs or strace output but it isn't the case.

It is theoretically possible to make the code faster.  But since the host database is handled using NSS it would require a special, new NSS function.  And probably it would only work if all NSS modules have this support.  Adding such a NSS function is no small feat.  Given that hosts.equiv really shouldn't be used I don't think it is worth it _at all_.

Note You need to log in before you can comment on or make changes to this bug.