Bug 614454

Summary: cannot switch VT when booted using systemd
Product: [Fedora] Fedora Reporter: Michal Schmidt <mschmidt>
Component: systemdAssignee: Lennart Poettering <lpoetter>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 14CC: lpoetter, mcepl, mcepl, metherid, orion
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-08-02 16:02:18 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
dmesg with systemd.log_level=debug none

Description Michal Schmidt 2010-07-14 14:24:02 UTC
Description of problem:
When I boot with init=/bin/systemd into graphical mode (gdm, Gnome) I am unable to switch to a different VT.
CTRL+ALT+F<n> have no effect
sudo chvt 3  causes the screen to redraw (blackness can be seen for a tiny fraction of a second), but nothing more. The command does not even finish, I have to press CTRL+C to end it. When I run it under strace I get:

...
open("/proc/self/fd/0", O_RDWR)         = 3
ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(3, KDGKBTYPE, 0x7ffff57889bf)     = -1 EINVAL (Invalid argument)
close(3)                                = 0
open("/dev/tty", O_RDWR)                = 3
ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(3, KDGKBTYPE, 0x7ffff57889bf)     = -1 EINVAL (Invalid argument)
close(3)                                = 0
open("/dev/tty0", O_RDWR)               = 3
ioctl(3, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0
ioctl(3, KDGKBTYPE, 0x7ffff57889bf)     = 0
ioctl(3, VT_ACTIVATE, 0x3)              = 0
ioctl(3, VT_WAITACTIVE^C <unfinished ...>

Version-Release number of selected component (if applicable):
systemd-3-3.fc14.x86_64

How reproducible:
always

Steps to Reproduce:
1. Boot into gdm using upstart (the default).
2. Try a VT switch, notice it works.
3. Reboot, this time use init=/bin/systemd
4. Try a VT switch.
  
Actual results:
VT is not switched.

Expected results:
VT switch should work.

Additional info:
In dmesg I am getting periodic messages:
systemd[1]: getty holdoff time over, scheduling restart.
systemd[1]: Unit getty entered maintenance state.

Comment 1 Michal Schmidt 2010-07-14 14:33:45 UTC
(In reply to comment #0)
> How reproducible:
> always

Correction: Almost always
I reproduced it 5 times. On the 6th boot VT switch worked. On the 7th it does not work again.

Comment 2 Lennart Poettering 2010-07-14 20:56:14 UTC
Hmm, we actually don't interfere with anything like that in any way. Mhmm, weird.

Could you please boot with "systemd.log_level=debug" on the kernel cmdline, then reproduce and post the output of dmesg here?

Comment 3 Michal Schmidt 2010-07-15 12:07:06 UTC
Created attachment 432061 [details]
dmesg with systemd.log_level=debug

Comment 4 Michal Schmidt 2010-07-15 12:46:42 UTC
I booted a few more times. Usually VT switching was broken, but on a couple of tries it worked. I found some important differences:

When VT switching works:
 - Xorg is running on tty7

When VT switching is broken:
 - Xorg is running on tty2
 - "mingetty tty2" periodically attempts to start, but cannot, because it gets -EPERM from ioctl(TIOCSCTTY).
 - after killing Xorg, it gets respawned on tty7 and then VT switching starts working.

Comment 5 Orion Poplawski 2010-07-16 22:58:26 UTC
Ah, there are some lovely race conditions with X and mingetty startup and several previous bugs have dealt with this.  I'm sure systemd introduces new yumminess into the mix.

Comment 6 Michal Schmidt 2010-07-27 13:24:13 UTC
With systemd-4-3.fc14 the behaviour has changed a bit (presumably because of http://cgit.freedesktop.org/systemd/commit/?id=36adffeab07c74470bc96417b17a72b53055ee42), but it's still not correct.

I cannot switch VT from X. Let's see how Xorg is running:
$ ps -eo tty,cmd|grep [X]org
?        /usr/bin/Xorg :0 -nr -verbose -auth /var/run/gdm/auth-for-gdm-I8qqup/database -nolisten tcp vt1

gdm is forcing it to start on an active VT ("vt1" at the end of the command line) and Xorg does not have a controlling tty (the "?" mark).
/var/log/messages tells me that a mingetty instance is being repeatedly started on tty1 and it always dies after several seconds, sometimes with a message like:
/sbin/mingetty[2770]: tty1: invalid character 0x9c in login name
I guess that's because of Xorg writing some gibberish to the tty.

In upstart /etc/init/start-ttys.conf ensured that mingetty would not be started on tty1 in runlevel 5, probably to prevent exactly these collisions with Xorg.

Comment 7 Michal Schmidt 2010-07-27 13:33:53 UTC
So as a workaround, I have now deleted the symlink /etc/systemd/system/getty.target.wants/getty . Now Xorg starts reliably on tty1, no collision with mingetty, and I can switch between VTs.

Comment 8 Bug Zapper 2010-07-30 12:34:43 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 14 development cycle.
Changing version to '14'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 9 Lennart Poettering 2010-08-02 16:02:18 UTC

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