Bug 13623 - GDM/KDM misbehave if XFree can't start
Summary: GDM/KDM misbehave if XFree can't start
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: gdm (Show other bugs)
(Show other bugs)
Version: 7.1
Hardware: i386 Linux
medium
medium
Target Milestone: ---
Assignee: Havoc Pennington
QA Contact:
URL:
Whiteboard:
Keywords:
: 13786 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2000-07-09 15:58 UTC by Ed McKenzie
Modified: 2008-05-01 15:37 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-04-07 06:01:18 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
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 06:00 UTC, Ed McKenzie
no flags Details | Diff
patch against specfile for 2.0beta4-45 (517 bytes, patch)
2001-04-07 06:01 UTC, Ed McKenzie
no flags Details | Diff

Description Ed McKenzie 2000-07-09 15:58:02 UTC
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 14:52:38 UTC
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 19:22:26 UTC
*** Bug 13786 has been marked as a duplicate of this bug. ***

Comment 3 Havoc Pennington 2000-07-18 17:06:37 UTC
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 05:17:32 UTC
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 20:25:21 UTC
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
interaction.


Comment 6 Ed McKenzie 2001-01-13 01:30:58 UTC
gdm-2.0.95 seems to fix all of these issues.

Comment 7 Ed McKenzie 2001-03-07 15:42:45 UTC
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 05:58:08 UTC
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 06:00:06 UTC
Created attachment 14863 [details]
loopofdeath2 -- gdm timeout for broken login displays

Comment 10 Ed McKenzie 2001-04-07 06:01:15 UTC
Created attachment 14864 [details]
patch against specfile for 2.0beta4-45

Comment 11 Havoc Pennington 2001-07-12 19:25:57 UTC
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.