Automatic unity 2D fallback does not work with remote login

Additional note: If I manually select "Ubuntu 2D" and run /usr/lib/nux/unity_support_test in the Unity 2D session with -p, it correctly fails:

$ /usr/lib/nux/unity_support_test -p
Error: no composite extension
$ echo $?
1
$

But if I run it with no arguments, it succeeds:

$ /usr/lib/nux/unity_support_test
$ echo $?
0
$

Looking in the unity_support_test source code, I can see the problem. unity_support_test caches the result of the test by creating an empty file at /tmp/unity_support_test.<exit code>. When run with no arguments, if /tmp/unity_support_test.0 exists, it immediately exits with success without checking for support. This scheme is fundamentally incompatible with running multiple X11 servers. In my case, the system has both a physical X11 display with COMPOSITE and GLX run by xserver-xorg and also virtual X11 displays for remote logins run by vnc4server. Once anyone logs in on the physical server and unity_support_test creates the /tmp/unity_support_test.0 file, all following remote logins are guaranteed to incorrectly pass the test.

To fix the bug, unity_support_test either should not cache the results of the test or should cache the results separately for each X11 server. For example, the value of the DISPLAY environment variable could be embedded into the filename. Though there is no guarantee that the configuration of a given X11 server remains constant over time, so it would be more robust to simply not cache at all.

Also worth noting that creating a file in /tmp without O_EXCL is a security risk. See e.g. http://www.dwheeler.com/secure-programs/Secure-Programs-HOWTO/avoid-race.html

The cache per display doesn't seem to be robust enough. However, the caching is still needed as it saved quite a bunch of boot time. If someone is wanting to work on that, he's more than welcome to do so, I'm afraid I have unfortunatly no time to work on it.

Could you expand on why caching per display was not robust?

>Could you expand on why caching per display was not robust?

I agree with Didier that caching per display is not robust, since differently configured X servers can potentially occupy the same display over time. However, the current implementation is simply broken - this really needs to be fixed.

I also did some (very) quick tests on cached vs uncached runs of unity_support_test, and the difference was extremely negligable. Unless I'm missing something, removing the cache completely should be very little work, and also fix the fallback behaviour.

FYI, Didier explained to me off-bug that the problem with caching per display is that sometimes the _same_ X server occupies a _different_ display over time, meaning it doesn't benefit from caching with that change:

"We only want to test once the acceleration per display per boot. It seems that under some circumstances, lightdm switch the VT (and anyway, it's the plan for next cycle, only play with VT switch), so caching per display won't fix in the long term the issue you are encountering. I think we need to think is in a deeper way to find a solution even working in your use case."

Ideally I would like to just drop the cache too, but apparently that's not an option. :/

This bug should also be marked as a security issue on account of the O_EXCL problem (see comment #4), but I couldn't figure out how to add the security flag to the bug.

Agree about the security issue. I would also like to see some evidence that the caching saves "quite a bunch of boot time". Didier - do you have any references?

@Aaron: we did some in the oneiric cycle, but it seems the pages were removed. We won 0.8s on desktop login time, which is exactly 20% of the budget we have theorically to log into the desktop.

Out of curiosity, how is this 4s budget defined? I assume it's from the time you enter your password in lightdm to the time you have a usable desktop? If this is the case, then it's arguable that lightdm shouldn't even be displaying "unity" as an option on displays which don't support it, let alone have it as the default option. If the unity_support_test was done as part of lightdm startup instead, and the 4s budget is defined as I assume it is, then at least the 0.8s unity_support_test delay could be moved outside of the desktop login process.

In this scenario, calling gnome-session with the '--session' parameter (as lightdm currently does) would invariably launch whatever session was specified using this parameter, and unity_support_test would never need to run or cache anything. The only time unity_support_test would be called during gnome-session startup is when it is called without the --session parameter; in this scenario, the session defaults to the value of the gsettings key "session-name" in org.gnome.desktop.session, as per current behaviour.

Of course, the next question is what this key should be by default. One option would be to have a new .session file, e.g. "unity-test.session" or similar. This session file would essentially look like the current ubuntu.session file, which performs the unity_support_test and falls back to unity-2d if it fails. (Admitedly I'm not sure what else this key is used for, so feel free to correct me if doing this would have any adverse effects).

I'm just brainstorming here - I'm happy to submit a patch if you feel that something like this would be an acceptable solution. Something needs to be done, however; the current implementation makes wild and unreasonable assumptions, is a potential security risk, and basically prevents Ubuntu from being a viable terminal server platform.

My friend uses Fallback mode and auto log-in. after installing updates yesterday, it did error as described. I tried reinstalling from a newer daily update and still, the problem remained. The desktop would be there but there would be no upper control menu-bar. Also, if you hit CTRL-ALT-DEL expecting to see "Restart, Cancel, and Shutdown" you were actually presented with "Cancel, and Log-out" . I reinstalled from Beta 2 and did not install fallback . I have her computer up and running but am afraid to update again.

It also affects remote NX (NoMachine) sessions.
My configuration: precise 12.04, 3.2.0-30-generic, GNOME 3.4.2, nxserver 3.5.0-11.
Client: Any NX 3.5.x client, and NoMachine Player 4.0.181-5

The current workaround is to delete (better: symlink) the file /tmp/unity_support_test.0,
according to bug #833729 and the bug description above.

Problem persists, even with the newest Unity update from today.

The workaround still is (precision of comment #14):
  cd /usr/lib/nux
  sudo mv unity_support_test unity_support_test.original
  sudo ln -s /bin/false unity_support_test

Status changed to 'Confirmed' because the bug affects multiple users.