Bug 132204 (IT_45429)
| Summary: | glibc-nis-performance.patch causes gdm to hang | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 3 | Reporter: | Brent Fox <bfox> |
| Component: | glibc | Assignee: | Jakub Jelinek <jakub> |
| Status: | CLOSED ERRATA | QA Contact: | |
| Severity: | medium | Docs Contact: | |
| Priority: | high | ||
| Version: | 3.0 | CC: | drepper, k.georgiou, tao |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2004-12-20 18:14:12 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: | |||
|
Description
Brent Fox
2004-09-09 20:55:24 UTC
Here's some data entered by Peggy Proffitt: I did try an strace. The process involved with interpreting the password is gdm-binary, rather than gdm-greeter. The gdm-binary displays the message stating that the password must be changed (a pop-up). We then press the OK button on the message. The message pop-up exits. At this point, the trace shows that gdm-binary opens a socket with ypserv on the server (we traced ypserv as well to confirm that, also used netstat to see the port number). The gdm-binary process calls FUTEX_WAIT and sits forever. The ypserv process still seems to be polling the client, but the gdm-binary never logs any further activity. We have to kill the X server to clear the gdm hang. Some data from dlehman: Here's how I reproduced this: I set up an RHEL3 (U2) AS machine on a VLAN serving DNS, DHCP, and NIS. After editing /var/yp/Makefile to not merge shadow and passwd/group files, I created a user on it called test and ran "chage -d 0 test" to make sure the system would prompt for a new password after the user's first authentication. I setup an RHEL3-U2 box on the same net and configured it to authenticate using NIS. When I log in as user test via gdm I see the message saying I must change my password, but clicking "OK" leaves the gdm screen seeming hung. The same process on a console works fine (it prompts for current password, then new one). I isolated the patch that caused this behavior (glibc-nis-performance.patch, first applied to glibc-2.3.2-95.12). Building glibc-2.3.2-95.12 (or .20 or .26 for that matter) without applying the patch in question eliminated the hung gdm screen. Likewise, applying the patch to glibc-2.3.2-95.11 (which did not include the patch) causes the problem to appear where it did not previously. The call that appears to hang the gdm-binary process: futex(0x14d9a4, FUTEX_WAIT, 2, NULL <unfinished ...> Last days I tried to setup new clients based on FC2 with NIS. After logging out gdm hangs for 45 to 120 seconds. When I'm logged in on tty1, I get the message that interrupt 11 is disabled. We have network- and graphic-cards on interrupt 11. On RedHat9.0 based distros and earlier versions everything runs fine, but I did not test FC1 based distros Rainer Hamann The patch is in glibc-2.3.2-95.28 which ought to appear in U4 beta. I'm asking Peggy to test with glibc-2.3.2-95.30, which is a little newer. An errata 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-2004-586.html |