Bug 29975 - xf86OpenConsole: VT_WAITACTIVE failed: Interrupted system call
Summary: xf86OpenConsole: VT_WAITACTIVE failed: Interrupted system call
Alias: None
Product: xorg
Classification: Unclassified
Component: Server/DDX/Xorg (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: Xorg Project Team
QA Contact: Xorg Project Team
Depends on:
Reported: 2010-09-02 07:37 UTC by Albert Zeyer
Modified: 2018-06-12 18:44 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Description Albert Zeyer 2010-09-02 07:37:25 UTC

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
new VT!

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.
Comment 1 Albert Zeyer 2010-09-02 07:52:41 UTC
A related bug report for (K)Ubuntu:
Comment 2 Adam Jackson 2018-06-12 18:44:20 UTC
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.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.