In some cases, when I use KDM to start the XServer, the XServer startup hangs here (in the second ioctl):
if (ioctl(xf86Info.consoleFd, VT_ACTIVATE, xf86Info.vtno) < 0)
FatalError("xf86OpenConsole: VT_ACTIVATE failed: %s\n",
if (ioctl(xf86Info.consoleFd, VT_WAITACTIVE, xf86Info.vtno) < 0)
FatalError("xf86OpenConsole: VT_WAITACTIVE failed: %s\n",
I searched around and it seems that Linus has found out why:
"I have chased it down, and what happens is that the new X server is trying
to switch to its newly allocated virtual console, but the old X server that
was started by rhgb is exiting at the same time, and apparently depending
on pure luck (or lack of it), the old X server will switch back to the
original VT (VT#0) JUST AFTER the new X server has tried to switch to its
The end result is that when the new X server waits for that switch to take
effect, it will never happen (since we did actually switch to it, but then
the old X server switched back!), and it will wait forever - or rather, it
will wait until a timeout signal comes in, and at that point it will exit
with the above error!"
More details: https://bugzilla.redhat.com/show_bug.cgi?id=323501
They are trying to fix it there in a way that this specific case doesn't happen anymore.
However, I think it is also a bug in Xorg itself. There may be various possible reasons why VT_ACTIVATE succeeds but VT_WAITACTIVE will wait forever because in between, some other process has grabbed it.
A clean solution would be to do lock somehow the VT switching. I have read that this is possible, though very complicated and very messy.
Another possible fix/workaround would be do do the VT_ACTIVE in a endless loop in a separate thread and halt when either the VT_WAITACTIVE returns or when one of them return an error.
A related bug report for (K)Ubuntu:
Mass closure: This bug has been untouched for more than six years, and is not obviously still valid. Please file a new report if you continue to experience issues with a current server.