Impact: ConsoleKit sometimes fails to determine which VT is active, breaking many parts of the system. For example, any dialog that requires PolicyKit authentication cannot be unlocked.
Development branch: Fixed in https://launchpad.net/ubuntu/+source/consolekit/0.4.1-4ubuntu1 by retrying console opens if they return EIO.
Patch: https://bugs.launchpad.net/ubuntu/+source/consolekit/+bug/544139/+attachment/1728928/+files/consolekit_0.4.1-3ubuntu2.debdiff
TEST CASE: Unfortunately, this bug is not uniformly reproducible, and may take many reboot attempts or even not be reproducible at all on any given system. If it is reproducible, then you can either try unlocking an administration dialog such as System -> Administration -> Time and Date (which will fail with a broken version), or (quicker) check for the string "Error waiting for native console" in /var/log/daemon.log. A successful fix will always permit a user with administrative privileges to unlock administrative dialogs.
Regression potential: When it breaks (not necessarily every time), consolekit is effectively completely broken. The test case should be sufficient to ensure that it is working properly.
Original description follows (note that the discussion about why EINVAL was being returned does not correspond to the end result of investigating this bug, but is preserved here for the record):
Binary package hint: consolekit
A few times over the last couple of days, I've noticed some weird consolekit issues where it doesn't correctly determine which VT is active, causing a lot of things to break (eg, disk mounting, rebooting, suspending etc). The issue is solved by rebooting.
When it fails, I get a lot of messages in my daemon.log when consolekit starts:
WARNING: Error waiting for native console 5 activation: Invalid argument
This occurs because the following call fails with EINVAL:
ioctl (console_fd, VT_WAITACTIVE, num);
I discussed this with Scott on #ubuntu-desktop. To summarize, there is a window between GDM starting and the X server coming up where the ioctl that consolekit does on the VT's will fail. Unfortunately, consolekit starts around the time of this window. Here is the log:
<chrisccoulson> Keybuk - i mentioned a consolekit issue last week, and your name was mentioned there
<chrisccoulson> that might have been what you remember
<Keybuk> can you remember more about what you mentioned?
<chrisccoulson> Keybuk - a couple of times when I booted last week, consolekit was unable to determine what the active VT was
<chrisccoulson> and it was throwing out errors like this:
<chrisccoulson> WARNING: Error waiting for native console 5 activation: Invalid argument
<Keybuk> right
<Keybuk> but why is consolekit using that ioctl?
<Keybuk> that's only used when you switch VT
<chrisccoulson> Keybuk - it spawns a thread for each VT, which waits for it to become active
<chrisccoulson> so it can track where the active one is
<Keybuk> ok
<Keybuk> it'll fail with -EINVAL for a short period during boot
<Keybuk> does it correctly back-off from that, and restart the thread again later?
<Keybuk> (if it goes into an infinite loop, that's not good either)
<chrisccoulson> Keybuk - no, that's probably the issue really. once it has failed, it just gives up
<chrisccoulson> so, we probably need to fix consolekit then?
<Keybuk> yeah
<Keybuk> we caused X to have the same bug
<chrisccoulson> ah, ok. that makes sense. and that explains why i can't recreate it all the time
<Keybuk> you get -EINVAL from VT_WAITACTIVE in a very specific condition
<Keybuk> the current foreground VT is in KD_GRAPHICS mode, but also VT_AUTO
<Keybuk> ie. it's been left with painted graphics ... but no process running on it
<Keybuk> since it's in graphics mode, the kernel prohibits VT switches
<Keybuk> can you guess when that condition is true?
<chrisccoulson> do you know how long it's in that condition for?
<Keybuk> chrisccoulson: however long the X server takes to start ;-)
<Keybuk> couple of seconds usually
<chrisccoulson> oh, right. that seems obvious now :)
<chrisccoulson> Keybuk - so the window is quite large then (and I think consolekit is activated after GDM starts isn't it?)
<chrisccoulson> i think gdm is the first thing to use it anyway
<Keybuk> chrisccoulson: gdm activates it
<chrisccoulson> yeah, i thought so
<chrisccoulson> thanks
<Keybuk> which means it's activated "before X starts or while X is starting"
<Keybuk> ie. exactly in that window
<Keybuk> chrisccoulson: so, on the VT_WAITACTIVE+VT_AUTO thing ... you could kinda argue it's a kernel bug
<Keybuk> because the kernel bug should deal with that case on its own
<Keybuk> but the kernel guys will tell you that the whole VT_* stuff is a mess, and they'd rather leave it alone
<chrisccoulson> yeah, it might be easier to work around it in consolekit for now
<Keybuk> exactly
Given that I'm still seeing these symptoms on an up-to-date Lucid installation, I'm assuming there's been no movement on this.
Can anyone suggest a more elegant work-around than 'log in and out a few times until things work again'?