Red Hat Bugzilla – Bug 132204
glibc-nis-performance.patch causes gdm to hang
Last modified: 2007-11-30 17:07:04 EST
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.
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
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
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
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.