Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
Bug 13623 - GDM/KDM misbehave if XFree can't start
GDM/KDM misbehave if XFree can't start
Product: Red Hat Linux
Classification: Retired
Component: gdm (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Havoc Pennington
: 13786 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2000-07-09 11:58 EDT by Ed McKenzie
Modified: 2008-05-01 11:37 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-04-07 02:01:18 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
loopofdeath2 -- gdm timeout for broken login displays (1.02 KB, patch)
2001-04-07 02:00 EDT, Ed McKenzie
no flags Details | Diff
patch against specfile for 2.0beta4-45 (517 bytes, patch)
2001-04-07 02:01 EDT, Ed McKenzie
no flags Details | Diff

  None (edit)
Description Ed McKenzie 2000-07-09 11:58:02 EDT
While playing with kernel 2.3 and devfs enabled, I discovered that if the 
mouse device is not available and X can't start up, gdm/kdm/xdm will 
restart the X server ad infinitum. A possible fix might be to have gdm/kdm 
only attempt to restart the X server if the error wasn't fatal (I haven't 
done too much messing with the gdm sources, but the Xserver error codes 
seem pretty clearly defined in the toplevel code.)

Another possible fix might be to have gdm/kdm adopt an init(1)-style 
respawn policy -- say, the Xserver can only be started X times per five 
minutes before a mandatory timeout.
Comment 1 David Mason 2000-07-10 10:52:38 EDT
hp - I think this is the problem of not finding the correct font because it was
not loaded - but this person is correct - we need to handle errors better than
just restarting continuously
Comment 2 Havoc Pennington 2000-07-13 15:22:26 EDT
*** Bug 13786 has been marked as a duplicate of this bug. ***
Comment 3 Havoc Pennington 2000-07-18 13:06:37 EDT
This is theoretically fixed in the latest build, but I'm not yet closing the bug 
since I'd like people to try it out first.
Comment 4 Havoc Pennington 2000-08-06 01:17:32 EDT
gdm now puts a limit on how many times it will try to start the X server.
This should be working in Pinstripe.
Comment 5 Ed McKenzie 2000-12-05 15:25:21 EST
The behavior in 7.0 is somewhat better, but it could still be better. gdm
appears to try launching the Xserver only five times before giving up, which is
good, but the timeout before it starts trying again is too short. It's not
nearly enough time to login as root and do an 'init 3'.

I'd suggest a timeout of at least one minute before starting up the Xserver again.

(This came up for me because I upgraded to 2.2.18pre, which has a different
version of the DRI than the one supplied in 2.2.16-22. XFree, in typical
fashion, didn't deal with it gracefully at all. If/when RH releases a 2.2.18 or
2.4 update, an XFree86 update had better be released real-soon-afterwards for
DRI users, or woe be to bugzilla :)

The obviously-correct fix long term is probably to have XFree deal with errors
in a more intelligent fashion. Logging a warning when DRI can't be loaded/mouse
isn't found/whatever is better than the silly nonsense arising from X/xdm/gdm
Comment 6 Ed McKenzie 2001-01-12 20:30:58 EST
gdm-2.0.95 seems to fix all of these issues.
Comment 7 Ed McKenzie 2001-03-07 10:42:45 EST
The current gdm behavior for X failure is better than for pre-7.0, but it's
still pretty difficult to log in to fix it. This is probably a machine-dependent
situation, but on my box, X tries to start up several times in a row, pauses for
a moment, and tries several more times, ad infinitum. The pause isn't really
long enough to even log in as root, much less type 'init 3.' Rebooting is much
less frustrating, and doesn't leave bits of root's password on VT7. :)

gdm-2.0.95 seems to have a nice way of dealing with this -- rather than pausing
and going back into the cycle again, it just drops into runlevel 3.
Comment 8 Ed McKenzie 2001-04-07 01:58:08 EDT
Ok, I had a look at this myself. Attached are patches for gdm/daemon/server.c
and the specfile for building the rpm. Comments? Flames? You know where to find
me ...
Comment 9 Ed McKenzie 2001-04-07 02:00:06 EDT
Created attachment 14863 [details]
loopofdeath2 -- gdm timeout for broken login displays
Comment 10 Ed McKenzie 2001-04-07 02:01:15 EDT
Created attachment 14864 [details]
patch against specfile for 2.0beta4-45
Comment 11 Havoc Pennington 2001-07-12 15:25:57 EDT
gdm codebase is totally changed now, and handles this case a lot better. It even
runs XConfigurator for you if X is hosed (questionable, but cute).

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