Description of problem: An attempt to switch users from the screen lock dialog led to an apparently dead session. Version-Release number of selected component (if applicable): [Among the suspect packages may be:] Name : gdm Version : 2.18.4 Release : 2.fc7 Name : fast-user-switch-applet Fast User Switch Applet 2.17.4 Version : 2.17.4 Release : 5.fc7 How reproducible: Once was enough. (A second attempt did not fail. Am willing to try more if advised what additional debugging info may be helpful. In the meantime, I no longer consider the "Switch User" command button to be a reliable technique.) Steps to Reproduce: 1. Two users, A and B, are logged in on the system. 2. Happily use fast-user-switch-applet in top panel to switch from A to B and vice versa multiple times. 3. User A was last one active. 4. Screen has locked (with blank screensaver) by automatic idle timeout. Instead of merely supplying the password for User A in the screen lock dialog and implicitly using the "Unlock" command button, selected the "Switch User" command button. Actual results: A blank (black, just like the screensaver) screen. But no cursor could be made to appear by wiggling the pointing devices.. No response to usual keypresses. Ctrl+Alt+F1 to a terminal session, "top" shows nothing unusual (e.g. X is NOT consuming 100% CPU), so system should be responsive. Alt+F7 back to X session still shows a blank unresponsive screen. Eventually give up (resign myself to losing collection of tasks in progress), Ctrl+Alt+Backspace to restart X. The X login screen shows user A as still logged in, but user B as NOT logged in! Supply the password for user A. Now in the resulting X session for user A, curiosity leads to the discovery that the fast-user-switch-applet still claims user B is logged in. (Maybe that collection of tasks is not lost, after all!) So use fast-user-switch-applet as usual to attempt to switch to user B. The result was (again) a blank (black, just like the screensaver) screen. But no cursor could be made to appear by wiggling the pointing devices. No response to usual keypresses. Expected results: When attempt to switch to user B (whether via fast-user-switch-applet as usual, or via "Switch User" command button on screen lock dialog) and supply the correct password, the reward should be a return to the active X session. Additional info: Per System Monitor, the User Memory was ~ 90% full, and Used Swap was ~ 80%, so some response times were lengthened by waiting for completion of disk accesses. (Large image editing tasks were in progress.) As noted above, the system was not CPU bound at this time. Speculation: Did some attempt at accessing a system file timeout prematurely to cause this failure? The only unusual bits in /var/log/messages were: - - - Oct 10 18:56:43 localhost gdmgreeter[5373]: The accessibility registry was not found. Oct 10 18:57:05 localhost gdm[2199]: Couldn't authenticate user Oct 10 18:57:38 localhost last message repeated 11 times Oct 10 18:58:39 localhost last message repeated 20 times Oct 10 18:59:40 localhost last message repeated 20 times Oct 10 19:00:43 localhost last message repeated 21 times Oct 10 19:01:44 localhost last message repeated 19 times Oct 10 19:02:47 localhost last message repeated 19 times Oct 10 19:03:48 localhost last message repeated 19 times Oct 10 19:04:49 localhost last message repeated 20 times Oct 10 19:05:50 localhost last message repeated 20 times Oct 10 19:06:53 localhost last message repeated 21 times Oct 10 19:07:38 localhost last message repeated 15 times - - -
have you made any PAM changes recently? Oct 10 18:57:05 localhost gdm[2199]: Couldn't authenticate user suggests that the gdm pam conversation is failing. The screensaver not bringing up a lock dialog (assuming that's what happens) suggests the screensaver pam conversation failing. Can you attach /etc/pam.d/system-auth?
Created attachment 235001 [details] attached /etc/pam.d/system-auth I have issued no PAM commands. The timestamps of this link and the linked file suggest they are untouched since installation: lrwxrwxrwx 1 root root 14 2007-05-25 08:49 system-auth -> system-auth-ac -rw-r--r-- 1 root root 887 2007-05-25 08:49 system-auth-ac
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists. Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs: http://docs.fedoraproject.org/release-notes/ The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 7 changed to end-of-life (EOL) status on June 13, 2008. Fedora 7 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.