Bug 140378 (IT_53059)
Summary: | [RHEL3] glibc behavior with long lines in /etc/hosts | ||||||
---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Linux 3 | Reporter: | David Lehman <dlehman> | ||||
Component: | glibc | Assignee: | Jakub Jelinek <jakub> | ||||
Status: | CLOSED ERRATA | QA Contact: | Brian Brock <bbrock> | ||||
Severity: | medium | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | 3.0 | CC: | ezannoni, jrfuller, roland, tao | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | RHBA-2005-096 | Doc Type: | Bug Fix | ||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2005-05-18 13:59:58 UTC | Type: | --- | ||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
Description
David Lehman
2004-11-22 17:44:38 UTC
Created attachment 107203 [details]
hosts file demonstrating line length limitation
I rebuilt glibc-2.3.2-95.27 with the patch from the above libc-hacker post and it seems to solve the problem completely for me. When might this appear in an RHEL3 update/errata? It should appear in RHEL3 U5. This is fixed for RHEL4 in glibc-2.3.3-86 (and for Fedora Core will be RSN), so just RHEL3 remains. This works great. There is one remaining question as nscd still will fail on sufficiently long lines (though with this fix, those after it will still work). Do we know what that limitation is (or is supposed to be)? Fix added to glibc-2.3.2-95.31, for the time being available from ftp://people.redhat.com/jakub/glibc/2.3.2-95.31/ From the client who originally posted the issue, there is still the one remaining question on the allowable length of a line in /etc/hosts when nscd is in use. They're looking to understand the limitation so that they can pass guidelines to their admin groups. There is no fixed limit. The code will dynamically allocate a buffer as needed to contain whatever data there is. The bug was in the logic that noticed that the original buffer was too small and allocated a larger buffer to retry the read. With the glibc fix, it should resize the buffer correctly and have no limit but available memory. Note that applications need to be written to handle the case of unusually large data, by recognizing the ERANGE error from get*_r and calling it again with a larger buffer. Indeed, this is a glibc bug. See http://sources.redhat.com/ml/libc-hacker/2005-02/msg00054.html for a fix. The RHEL3 backport of that patch is similar, but not identical. A fixed RHEL3 glibc candidate at ftp://people.redhat.com/jakub/glibc/2.3.2-95.33/ An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on the solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2005-256.html |