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.
(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.
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?
Created attachment 432061 [details] dmesg with systemd.log_level=debug
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.
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.
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.
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.
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
*** This bug has been marked as a duplicate of bug 619889 ***