Bug 345211 - Switch User failure, "The accessibility registry was not found."
Switch User failure, "The accessibility registry was not found."
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: gdm (Show other bugs)
7
i686 Linux
low Severity medium
: ---
: ---
Assigned To: Ray Strode [halfline]
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-10-22 09:59 EDT by xunilarodef
Modified: 2008-06-16 22:43 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-06-16 22:43:16 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
attached /etc/pam.d/system-auth (887 bytes, text/plain)
2007-10-23 08:06 EDT, xunilarodef
no flags Details

  None (edit)
Description xunilarodef 2007-10-22 09:59:19 EDT
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
- - -
Comment 1 Ray Strode [halfline] 2007-10-22 10:06:35 EDT
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?
Comment 2 xunilarodef 2007-10-23 08:06:19 EDT
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
Comment 3 Bug Zapper 2008-05-14 10:49:35 EDT
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
Comment 4 Bug Zapper 2008-06-16 22:43:14 EDT
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.

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