Bug 132204 - (IT_45429) glibc-nis-performance.patch causes gdm to hang
glibc-nis-performance.patch causes gdm to hang
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: glibc (Show other bugs)
All Linux
high Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Depends On:
  Show dependency treegraph
Reported: 2004-09-09 16:55 EDT by Brent Fox
Modified: 2007-11-30 17:07 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-12-20 13:14:12 EST
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 00:00:00 EST

  None (edit)
Description Brent Fox 2004-09-09 16:55:24 EDT
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 16:57:31 EDT
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 16:58:35 EDT
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 02:19:16 EDT
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 14:30:52 EDT
The patch is in glibc-2.3.2-95.28 which ought to appear in U4 beta.
Comment 11 Brent Fox 2004-11-11 11:41:02 EST
I'm asking Peggy to test with glibc-2.3.2-95.30, which is a little
Comment 13 John Flanagan 2004-12-20 13:14:12 EST
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.