Bug 119036 - Gnome logout tries to start xserver on new display
Summary: Gnome logout tries to start xserver on new display
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: nss_ldap
Version: 3.0
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Nalin Dahyabhai
QA Contact: Jay Turner
Depends On:
TreeView+ depends on / blocked
Reported: 2004-03-24 04:09 UTC by wilburn
Modified: 2015-01-08 00:07 UTC (History)
4 users (show)

Clone Of:
Last Closed: 2007-10-19 19:28:38 UTC

Attachments (Terms of Use)
Modified gdm.conf (15.73 KB, text/plain)
2004-03-30 00:55 UTC, wilburn
no flags Details

Description wilburn 2004-03-24 04:09:13 UTC
Description of problem:

Every time I log out of gnome I get the

"There already appears to be an X server running on display :0. Should
I try another display number?..."

message. Selecting 'No' restarts the xserver on :0 with no problem.

Version-Release number of selected component (if applicable):


How reproducible:

Happens every time on two different machines, with different video
cards. /etc/X11/XF86Config has

Section "Device"
        Identifier  "Videocard0"
        Driver      "nv"
        VendorName  "Videocard vendor"
        BoardName   "NVIDIA GeForce 2 GTS (generic)"
        VideoRam    32768

for one machine and

Section "Device"
        Identifier  "Videocard0"
        Driver      "mga"
        VendorName  "Videocard vendor"
        BoardName   "Matrox Millennium G200"
        VideoRam    8192

for the other. Happens to other users too, so not due to any
user-specific settings.

Steps to Reproduce:
1. Gnome login
2. Logout
Actual results:

Error message reporting existing xserver on display :0.

Expected results:

Restarts xserver on :0 with no error message.

Additional info:

Comment 1 wilburn 2004-03-30 00:55:38 UTC
Created attachment 98949 [details]
Modified gdm.conf

Comment 2 wilburn 2004-03-30 00:56:58 UTC
More information:

1. This problem also occurs when logging out of a KDE session.

2. This problem does NOT occur when logging out of a 'failsafe' session.

3. I have modified gdm.conf slightly (attached), but since KDE also
has problem, this seems unlikely to be culprit.

4. I see this on 5 different machines, i.e. all I have with RHEL3.

5. No machines with RH9, but similar configs, have this problem.

Comment 3 wilburn 2004-04-11 17:33:50 UTC
cp /etc/X11/gdm/factory-gdm.conf /etc/X11/gdm/gdm.conf
telinit 3
telinit 5

does not fix problem. Date of /etc/X11/gdm/factory-gdm.conf is Sep  2

Comment 4 wilburn 2004-04-20 20:10:10 UTC
The problem only occurs with usernames obtained from ldap, not
/etc/passwd. In addition, removing the

   session         optional        /lib/security/pam_ldap.so

line from the pam file fixes the problem. Some observations:

1. I do not know if this is a bug (probably in pam_ldap, perhaps it
should be reassigned), or a configuration error. 

2. The problem has not always existed. Although I can't recall exactly
when the problem arose, there has been a fairly recent update to nss_ldap.

2. I don't see any messages logged that shed light on the problem.

3. I can't find any docs on what pam_ldap does as a session module.
Perhaps it is not needed.

Suggestions for further tests welcome.

Comment 5 Mike A. Harris 2005-03-06 23:13:13 UTC
Adding pam maintainer for comment/feedback.

Comment 6 Tomas Mraz 2005-03-07 09:35:20 UTC
It's probably bug http://bugzilla.padl.com/show_bug.cgi?id=142

CCing nalin as he's the owner of nss/pam_ldap.

Comment 7 Nalin Dahyabhai 2005-03-08 20:12:09 UTC
Can you check if nss_ldap-207-15 from
http://people.redhat.com/nalin/test/ resolves this?  It incorporates
the fix for the upstream bug to which Tomas points, and would shed
some light on whether or not it's the trigger.

Comment 8 Mike A. Harris 2005-05-12 07:42:23 UTC
This does not sound like an X server or video driver problem at all, in
particular looking at comment #4 through #7.  Reassigning to pam

Comment 9 RHEL Product and Program Management 2007-10-19 19:28:38 UTC
This bug is filed against RHEL 3, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products. Since
this bug does not meet that criteria, it is now being closed.
For more information of the RHEL errata support policy, please visit:
If you feel this bug is indeed mission critical, please contact your
support representative. You may be asked to provide detailed
information on how this bug is affecting you.

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