Bug 446018

confirmed.  I think this may be best looked into by the upstart folks, though. 
Reassigning there.

How did you install/upgrade? This works fine for me.

Fresh F9-Beta2 installation, updated to latest rawhide.
P.S. I'm at init 5. (not 3)

- Gilboa

Need 'rpm -q initscripts upstart event-compat-sysv'

(and rpm -V on the above, as well) Theoretically, event-compat-sysv is not
installed.

Mine was a rawhide install as of some date :)  (a somewhat recent date, because
my root filesystem got eaten up and I had to reinstall - I'd say 3-6 weeks ago).

$ rpm -q initscripts event-compat-sysv upstart
initscripts-8.76-1.x86_64
package event-compat-sysv is not installed
upstart-0.3.9-19.fc9.x86_64
 
$ rpm -qV initscripts event-compat-sysv upstart
..5....T  c /etc/inittab
package event-compat-sysv is not installed

Looking into the difference between /etc/inittab as shipped and on the system,
it's inconsequential:

$ diff etc/inittab /etc/inittab 
26c26
< id:3:initdefault:
---
> id:5:initdefault:

What does 'initctl list' say after you get a tty 'stuck' in this way?

Don't know what the latest upgrade contained, but I cannot seem to reproduce
this problem. VTs respawn just fine.

- Gilboa

Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Jon, Gilboa - what desktop environment are you using?

Same problem here: VT did not respawn.

% rpm -q initscripts upstart event-compat-sysv
initscripts-8.76.1-1.x86_64
upstart-0.3.9-19.fc9.x86_64
package event-compat-sysv is not installed

% sudo initctl list
control-alt-delete (stop) waiting
logd (stop) waiting
prefdm (stop) waiting
rc0 (stop) waiting
rc1 (stop) waiting
rc2 (stop) waiting
rc3 (stop) waiting
rc4 (stop) waiting
rc5 (stop) waiting
rc6 (stop) waiting
rcS (stop) waiting
rcS-sulogin (stop) waiting
serial (instance)
sulogin (stop) waiting
tty1 (stop) waiting
tty2 (stop) waiting
tty3 (stop) waiting
tty4 (stop) waiting
tty5 (stop) waiting
tty6 (stop) waiting

X is running fine, desktopmanager is kdm. after

% sudo initctl start prefdm
prefdm (start) waiting
prefdm (start) starting
prefdm (start) pre-start
prefdm (start) spawned, process 27211
prefdm (start) post-start, (main) process 27211
prefdm (start) running, process 27211

consoles come back and even respawn. We now have:

% sudo initctl list
control-alt-delete (stop) waiting
logd (stop) waiting
prefdm (stop) waiting
rc0 (stop) waiting
rc1 (stop) waiting
rc2 (stop) waiting
rc3 (stop) waiting
rc4 (stop) waiting
rc5 (stop) waiting
rc6 (stop) waiting
rcS (stop) waiting
rcS-sulogin (stop) waiting
serial (instance)
sulogin (stop) waiting
tty1 (start) running, process 27216
tty2 (start) running, process 27214
tty3 (start) running, process 27215
tty4 (start) running, process 27212
tty5 (start) running, process 27213
tty6 (start) running, process 27217

(In reply to comment #9)
> Jon, Gilboa - what desktop environment are you using?

KDE.
But I did manage to reproduce it (and I cannot seem to reproduce it
consistently) with only GDM active.

- Gilboa

I have also been able to reproduces this.

Right now, the system looks like this:

[todd@hobbes ~]$ sudo /sbin/initctl list
control-alt-delete (stop) waiting
logd (stop) waiting
prefdm (stop) waiting
rc0 (stop) waiting
rc1 (stop) waiting
rc2 (stop) waiting
rc3 (stop) waiting
rc4 (stop) waiting
rc5 (stop) waiting
rc6 (stop) waiting
rcS (stop) waiting
rcS-sulogin (stop) waiting
serial (instance)
sulogin (stop) waiting
tty1 (start) running, process 12387
tty2 (start) running, process 12105
tty3 (start) running, process 11857
tty4 (stop) waiting
tty5 (stop) waiting
tty6 (stop) waiting

I had logged in and out of tty1, tty2, and tty3.  After logging out they all
showed a blank screen and did not return a login prompt.  I then restarted them
with initctl start tty1 ; initctl start tty2 ; initctl start tty3.  They all got
a login prompt and went into the state shown above.  I have never logged into
tty4 yet, but these is a login prompt and a mingetty process running on it, even
though the above output shows it as stopped.

After logging into tty4, it still shows that it is stopped.

[todd@hobbes ~]$ sudo /sbin/initctl list tty4
tty4 (stop) waiting

I then logout of tty4.  The login prompt does not return and the state has not
changed:
[todd@hobbes ~]$ sudo /sbin/initctl list tty4
tty4 (stop) waiting

Issuing a start on tty4, kicks it into gear and the login prompt returns

[todd@hobbes ~]$ sudo /sbin/initctl start tty4
tty4 (start) waiting
tty4 (start) starting
tty4 (start) pre-start
tty4 (start) spawned, process 13387
tty4 (start) post-start, (main) process 13387
tty4 (start) running, process 13387
[todd@hobbes ~]$ sudo /sbin/initctl list tty4
tty4 (start) running, process 13387

This system was a F8 system upgraded via the DVD image to F9 with all the
current updates.

[todd@hobbes ~]$ rpm -q initscripts upstart event-compat-sysv
initscripts-8.76.1-1.i386
upstart-0.3.9-19.fc9.i386
package event-compat-sysv is not installed
[todd@hobbes ~]$ rpm -qV initscripts upstart event-compat-sysv
S.5....T  c /etc/inittab
..5....T  c /etc/sysctl.conf
package event-compat-sysv is not installed

Desktop is KDE, but GDM is used to login.

So this confirms that your gettys are being started by a source other than
upstart or are somehow becoming disassociated with upstart.

It also seems that manually starting the gettys causes them to come up and
remain managed.

Well, for runlevel 5 they're started by 'start on started prefdm'. If upstart
doesn't think prefdm started...

This issue is better explained in bug #450488

*** This bug has been marked as a duplicate of 450488 ***