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.
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
*** Bug 13786 has been marked as a duplicate of this bug. ***
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.
gdm now puts a limit on how many times it will try to start the X server.
This should be working in Pinstripe.
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
gdm-2.0.95 seems to fix all of these issues.
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.
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
Created attachment 14863 [details]
loopofdeath2 -- gdm timeout for broken login displays
Created attachment 14864 [details]
patch against specfile for 2.0beta4-45
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).