Red Hat Bugzilla – Bug 130066
"x" respawning too fast when starting X in runlevel 5
Last modified: 2007-11-30 17:07:03 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.3)
Description of problem:
Note: we have run into this problem on over a dozen systems; I'll just
give details for one or two here.
Starting with a new installation of RHEL 3.0 (original CDs, not update
1 or 2), I can boot into runlevel 5 and have X-windows/gdm start
normally, either with the Xfree VESA driver or the latest nVidia
driver (AGP video card has GeForce MX4000 chipset.)
After running up2date and installing all available packages, when I
subsequently reboot, X does not start but gives the message 'Id "x"
respawning too fast: disabled for 5 minutes'. When I log in now,
without X running, and type "startx" my desktop starts normally.
Similarly if I log in as root and run ". /usr/bin/gdm" the GDM login
screen appears. The same behavior happens with both the VESA driver
and 3rd-party nVidia driver. So I don't think there's a problem with
X in general here ... just a problem starting it via init in runlevel
5 with the latest set of RHEL updates.
On another system in our dept, we installed from the RHEL update 2 CD
and X worked fine. After putting on kernel-2.4.21-15.0.4.EL and
restarting, the problem described above started. Surprisingly, if we
then booted to the original kernel-2.4.21-15.0.2.EL, the problem still
I'm not sure what config files or log files would be useful here.
Please let me know if you'd like to see any of them. Also I can
provide more detailed HW info if warranted.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Boot system in runlevel 5
Actual Results: X does not start, message 'Id "x" respawning too
fast: disabled for 5 minutes" appears on console (and in
/var/log/messages every 5 minutes thereafter or until system is taken
to runlevel 3).
Expected Results: GDM login screen should appear.
First you'll need to uninstall the proprietary Nvidia driver, and
restore the Red Hat supplied xorg-x11 packages, as Nvidia's driver
overwrites several Red Hat supplied X server modules/libraries,
resulting in an unsupported OS installation.
Once you've removed the proprietary driver, and reproduced the
problem with the 'nv' or 'vesa' drivers, please attach the X
server log file and config file, as well as /var/log/messages from
the problematic setup.
Since the X server is running normally for you with startx, it is
difficult to determine what the problem is without additional
information. Please indicate any error messages you see on
screen at the console, etc. that might be related.
Thanks in advance.
I am attaching /etc/X11/XF86Config, /var/log/XFree86.0.log, and
the relevant part of /var/log/messages for a RHEL AS 3.0 system that
I just installed from scratch and which has never had any third-party
video drivers on it at all. Unfortunately it does show the problem
I've described originally.
In the case of the logs that I'm attaching, I booted directly into
runlevel 5, gdm didn't start, I logged in from another system and ran
". /usr/bin/gdm", X started and the gdm login screen appeared, and
then I logged in directly via the gdm login.
Created attachment 108050 [details]
Created attachment 108052 [details]
Created attachment 108053 [details]
/var/log/messages (for boot into runlevel 5 as described in Comment #2)
Some additional info: if in /etc/X11/prefdm I force the preferred
desktop to be xdm rather than the default (which in my case is gdm)
then X and the desktop login screen start normally when booting into
Could the problem be that you have to start gdm as ". /usr/bin/gdm"
but the prefdm script tries to "exec" it?
I figured out what the problem is. One of our configuration scripts in
/etc/profile.d echoes output to stdout. When the echo output is not produced
(eg when that part of the script is commented) gdm starts normally at boot time
in runlevel 5. I am not sure why the echo output causes the problem, but it's
easy to work around so this issue can be closed.
Closing "WORKSFORME", as per comment #8.