Bug 320281 - in.rlogind performance issues
Summary: in.rlogind performance issues
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: glibc
Version: 4.5
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
: ---
Assignee: Jakub Jelinek
QA Contact: Brian Brock
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2007-10-05 15:45 UTC by Chuck Mead
Modified: 2008-08-04 04:34 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2008-08-04 04:34:58 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Chuck Mead 2007-10-05 15:45:42 UTC
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:
1.
2.
3.
  
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 15:46:23 UTC
- 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 10:35:03 UTC
Reassigning to proper owner

Comment 3 Adam Tkac 2008-03-13 17:09:04 UTC
As far as I know glibc is responsible for parsing hosts file. Reassigning to
glibc for inspection

Comment 4 Ulrich Drepper 2008-08-04 04:34:58 UTC
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.