Bug 446018 - Console VTs (VT1-6) do not respawn after "exit"
Console VTs (VT1-6) do not respawn after "exit"
Status: CLOSED DUPLICATE of bug 450488
Product: Fedora
Classification: Fedora
Component: upstart (Show other bugs)
9
All Linux
low Severity low
: ---
: ---
Assigned To: Casey Dahlin
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-12 01:38 EDT by Gilboa Davara
Modified: 2014-06-18 04:46 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-06-09 02:25:59 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Gilboa Davara 2008-05-12 01:38:36 EDT
Version-Release number of selected component (if applicable):
initscripts-8.76-1.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Init 5.
2. Switch to text VT[1-6].
3. Login.
4. Logout.
  
Actual results:
Login prompt does not reappear.

Expected results:
Login prompt.

- Gilboa
Comment 1 Jon Stanley 2008-05-12 01:54:46 EDT
confirmed.  I think this may be best looked into by the upstart folks, though. 
Reassigning there.
Comment 2 Bill Nottingham 2008-05-12 11:53:25 EDT
How did you install/upgrade? This works fine for me.
Comment 3 Gilboa Davara 2008-05-12 13:18:54 EDT
Fresh F9-Beta2 installation, updated to latest rawhide.
P.S. I'm at init 5. (not 3)

- Gilboa
Comment 4 Bill Nottingham 2008-05-12 13:23:35 EDT
Need 'rpm -q initscripts upstart event-compat-sysv'

(and rpm -V on the above, as well) Theoretically, event-compat-sysv is not
installed.
Comment 5 Jon Stanley 2008-05-12 19:10:27 EDT
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:


Comment 6 Bill Nottingham 2008-05-12 20:17:42 EDT
What does 'initctl list' say after you get a tty 'stuck' in this way?
Comment 7 Gilboa Davara 2008-05-13 00:43:35 EDT
Don't know what the latest upgrade contained, but I cannot seem to reproduce
this problem. VTs respawn just fine.

- Gilboa
Comment 8 Bug Zapper 2008-05-14 07:01:00 EDT
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
Comment 9 Bill Nottingham 2008-05-16 17:22:41 EDT
Jon, Gilboa - what desktop environment are you using?
Comment 10 Thomas Moschny 2008-05-16 17:28:47 EDT
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
Comment 11 Gilboa Davara 2008-05-16 23:55:21 EDT
(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
Comment 12 Todd J Martin 2008-05-17 17:23:12 EDT
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.
Comment 13 Casey Dahlin 2008-05-17 17:29:46 EDT
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.
Comment 14 Bill Nottingham 2008-05-19 16:22:42 EDT
Well, for runlevel 5 they're started by 'start on started prefdm'. If upstart
doesn't think prefdm started...
Comment 15 Casey Dahlin 2008-06-09 02:25:59 EDT
This issue is better explained in bug #450488

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

Note You need to log in before you can comment on or make changes to this bug.