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 interaction.
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 me ...
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).