After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 342397 - gdm doesn't respond to XDMCP querys if local X server fails to start
gdm doesn't respond to XDMCP querys if local X server fails to start
Status: RESOLVED FIXED
Product: gdm
Classification: Core
Component: general
2.14.x
Other All
: Normal normal
: ---
Assigned To: GDM maintainers
GDM maintainers
Depends on:
Blocks:
 
 
Reported: 2006-05-20 09:11 UTC by David Basden
Modified: 2010-06-16 20:36 UTC
See Also:
GNOME target: ---
GNOME version: 2.11/2.12



Description David Basden 2006-05-20 09:11:41 UTC
Local setup:
  host system is Debian i386/testing with gnome desktop 2.12.3 and gdm 2.14.5 running Xorg 6.9.0.dfsg.1 with nvidia gforce 5200 FX and nvidia closed-source X drivers
  remote system is Debian i386/unstable running Xorg 7.0.17
  systems are connected by a 100baseT switch with IPv4 on the same /24

Normal operation:
  gdm on the host system allows XDMCP Query connections from the remote system.
  The remote system connects by running 'X -query <remoteservername>' and is promptly presented with a login screen to the host system.
  gdm continues to work as expected past this point

Triggers:
  When the host system fails to start the local X server for any reason[0], gdm doesn't answer the XDMCP query from the remote system.

Bug operation:
  When the host's local X server is down, The remote X server tries to connect by running 'X -query <remoteservername>', however only displays the default X11 crosshatch background and 'X' pointer indefinately.

Expected operation:
  As for normal operation when the local X server on the host system is running.
[0] In this case, whenever I upgrade the kernel, it breaks the nvidia kernel module version numbers, but i've also reproduced when the server won't start due to more mundane things such as being unable to talk to the mouse
Comment 1 Brian Cameron 2006-05-22 20:15:13 UTC
I would accept a patch to fix this problem.
Comment 2 Hans Petter Jansson 2009-01-15 17:59:05 UTC
This seems to be a problem with the new GDM as well. You can't run it on a headless server.
Comment 3 Brian Cameron 2009-01-15 19:17:16 UTC
Do you see this problem using GDM 2.20?  Would be good to see if this bug has been fixed there.  Would be useful to share the debug logs.  If using GDM 2.20 or earlier, you can run gdmsetup and turn on debug in the Security tab.
Comment 4 Hans Petter Jansson 2009-01-15 21:17:34 UTC
I don't have access to GDM 2.20 at the moment, so I don't know. We've switched to GDM 2.24 in openSUSE 11.1, so I'm primarily concerned about that.
Comment 5 holdenhao 2010-04-06 23:36:25 UTC
I am trying to run GDM (2.28.1) on Ubuntu 9.10 OpenVZ instance. OpenVZ clients normally do not have access to a graphical console.  So I can not run an XServer locally.  However, I want GDM to run without an XServer and serve XDMCP requests.  In previous GDM versions, the option to run it without requiring a running X server is possible by commenting out the 0=Standard option in the [server] section of gdm.conf or by running GDM with the option --no-console.  This option seems to be no longer available in newer versions of GDM.  A patch to enable no console option is available from this bug report:

https://bugzilla.gnome.org/show_bug.cgi?id=567522
Comment 6 William Jon McCann 2010-06-16 20:29:32 UTC
*** Bug 567522 has been marked as a duplicate of this bug. ***
Comment 7 William Jon McCann 2010-06-16 20:36:47 UTC
commit 64483254bde06c4bec9ea3bd0a01419dba520e36
Author: William Jon McCann <jmccann@redhat.com>
Date:   Wed Jun 16 16:32:20 2010 -0400

    Don't exit when local display fails to start
    
    It doesn't really make a lot of sense to exit when the
    local display can't be started.  Exiting won't leave the system
    in any better shape that it would be with gdm running in the
    background.  On the other hand it makes it so that XDMCP and other
    services can't run headless.  Ideally we'd have some kind of
    smart detection of when local hardware is available and when it
    changes.  And smarter fallback code for when the hardware is
    available but the display can't be started due to some error.
    
    https://bugzilla.gnome.org/show_bug.cgi?id=342397