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 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