Description of problem: Since FC10 the Xorg is started on tty1. But /etc/event.d/tty1 also starts a mingetty on tty1. So we have two processes concurrently accessing tty1. This results in mingetty respawing rapidly and is also cauing Xorg to have 100% cpu usage all the time (even when idle). There is a separat bugzilla entry #475890 describing the problem of xorg which leads to this bug report. Version-Release number of selected component (if applicable): initscripts-8.86-1 How reproducible: always (at least on two Thinkpad T43 laptops) Steps to Reproduce: 1. Boot system 2. log into KDE or GNOME 3. use "top" or other tool to watch constant load of "1". Actual results: Load of "1" on idle system. Expected results: Load of ~"0" on idle system. Additional info: SOLUTION: removing /etc/event.d/tty1 solves the problem.
This shouldn't happen. Can you attach your /etc/event.d/tty1?
Triaged. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Looks like Till has gone idle. I'm seeing the problem on a fully updated F-11; here's my /etc/event.d/tty1 (short enough that attaching it seems pointless): # tty1 - getty # # This service maintains a getty on tty1 from the point the system is # started until it is shut down again. start on stopped rc2 start on stopped rc3 start on stopped rc4 stop on runlevel 0 stop on runlevel 1 stop on runlevel 6 respawn exec /sbin/mingetty tty1 I can verify that a mingetty was started on tty1 at the time that a user last logged out of X on this (virtual) machine, and at that time X started chewing 100% CPU.
I often see this problem on my fc11 laptop. What happens is that sometimes when I boot my machine, kdm (or X) wont start. This I can fix by switching to VC2, logging in as root and running init 3 ; init 5. Then mingetty is running on vc1 (tty1) and thus I get X using 100% cpu on one of my cpu's. I just tried to log in on vc2 and killing kdm instead of switching runlevels and this got X up and running without starting mingetty on vc1. There are no errors in Xorg.0.log
This is almost certainly a consequence of bug #475890 alright, the pending kde-4.3.4 update should take care of that (and this).
can anyone confirm this bug with anything else than kdm? (as the original report mentions GNOME as well) if not, I'm going to close this as duplicate of bug #475890
*** This bug has been marked as a duplicate of bug 475890 ***