Bug 132204 (IT_45429) - glibc-nis-performance.patch causes gdm to hang
Summary: glibc-nis-performance.patch causes gdm to hang
Alias: IT_45429
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: glibc   
(Show other bugs)
Version: 3.0
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jakub Jelinek
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-09-09 20:55 UTC by Brent Fox
Modified: 2007-11-30 22:07 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-12-20 18:14:12 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2004:586 normal SHIPPED_LIVE Low: glibc security update 2004-12-20 05:00:00 UTC

Description Brent Fox 2004-09-09 20:55:24 UTC
Related to IssueTracker ticket #45429

Something changed between RHEL3 GA and RHEL3 U3 that causes gdm to
hang when using NIS when the user's password has expired.  dlehman has
tracked this down to the glibc-nis-performance.patch first
applied to glibc-2.3.2-95.12.

I will attach some information from the Issue Tracker ticket.

Comment 1 Brent Fox 2004-09-09 20:57:31 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.

Comment 2 Brent Fox 2004-09-09 20:58:35 UTC
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

The call that appears to hang the gdm-binary process:
futex(0x14d9a4, FUTEX_WAIT, 2, NULL <unfinished ...>

Comment 5 Rainer Hamann 2004-09-24 06:19:16 UTC
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 

Comment 10 Jakub Jelinek 2004-10-06 18:30:52 UTC
The patch is in glibc-2.3.2-95.28 which ought to appear in U4 beta.

Comment 11 Brent Fox 2004-11-11 16:41:02 UTC
I'm asking Peggy to test with glibc-2.3.2-95.30, which is a little

Comment 13 John Flanagan 2004-12-20 18:14:12 UTC
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.


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