login in nested window dies changing workspace

[Chris Jones]

I am starting the "New login in a nested window" menu item on its own workspace, logging in, then switching workspace a few times and working elsewhere.
When I come back to the xnest one, it has gone.

Running gdmflexiserver -d --xnest from a terminal gave:

Sending command: 'VERSION'
  Got response: 'GDM 2.16.1'
Sending command: 'GET_CONFIG daemon/PidFile :0.0'
  Got response: 'OK /var/run/gdm.pid'
Sending command: 'CLOSE'
Sending command: 'VERSION'
  Got response: 'GDM 2.16.1'
Sending command: 'AUTH_LOCAL dcbb6e54d76696357d03633b054517ce'
  Got response: 'OK'
Sending command: 'AUTH_LOCAL dcbb6e54d76696357d03633b054517ce'
  Got response: 'OK'
Sending command: 'QUERY_VT'
  Got response: 'OK 7'
Sending command: 'AUTH_LOCAL dcbb6e54d76696357d03633b054517ce'
  Got response: 'OK'
Sending command: 'CONSOLE_SERVERS'
  Got response: 'OK :0,cmsj,7'
Sending command: 'FLEXI_XNEST :0 1000 dcbb6e54d76696357d03633b054517ce /home/cmsj/.Xauthority'
  Got response: 'OK :20'
Sending command: 'CLOSE'

[Daniel Holbach (dholbach)]

Thanks for your bug report. I can't reproduce this as all. Which version of Ubuntu and gdm do you use? Do you get anything interesting in one of the users' ~/.xsession-errors?

[Chris Jones (cmsj)]

This is Edgy with all updates.

The xsession-errors shows some regular looking startup messages, then a few alsa errors about not being able to find a device, then it just seems like the server died.

ALSA lib pcm.c:2146:(snd_pcm_open_noupdate) Unknown PCM default
The application 'gnome-session' lost its connection to the display :20.0;
most likely the X server was shut down or you killed/destroyed
the application.

[Vincent Untz (vuntz)]

I'm also affected by this bug. It's not a gdm bug, though it's probably a xnest bug: it also happens if you run xnest from the command line...

[Sebastien Bacher (seb128)]

Vincent, how do you start xnest (what parameters do you use)? I've noticed that problem with gdmflexiserver several time but I didn't manage to crash xnest when I tried some time ago (by starting gdmflexiserver xnest and xnest on a workspace the bug happened only to the gdmflexiserver window)

[Vincent Untz (vuntz)]

I'm just doing "Xnest :1". It happens with gdmflexiserver but I'm 90% sure it also happened when I directly runned Xnest. Of course, it doesn't always happen :-)

[Ondrej Masek (nxtwrld)]

i experience the same bug running gdmflexiserver --xnest in Feisty amd64.
I turn the workspaces couple of times (running beryl) and the xnest window is gone - dies with no error output :(
When I check runnig processes I stil can see the gdm process, xnest is gone.
Xnest seems to disappear only when logged in though.

[Sandy Armstrong (sanfordarmstrong)]

I was having the same problem, running with `gdmflexiserver -n -l`.

I removed Network Manager from the GNOME Session for that user, and the problem went away.

Details:
Ubuntu 7.04 running on an older Pentium 4 desktop

Steps to reproduce (for me):
0. Logged in as main admin user "sandy".
1. Created regular (non-admin) user "test1".
2. Started GDM in XNest by running `gdmflexiserver -n -l`.
3. Logged in as user "test1".
4. Switched desktops a few times in the main X session (as "sandy").

Expected result:
Desktops switch, and "test1" XNest window is stil there when I come back to the first desktop.

Actual result:
Desktops switch, but "test1" XNest window is blown away at some point during the switching, and is no longer there when I come back to the first desktop.

I turned off GNOME Session programs one by one until the problem finally went away by removing Network Manager from the GNOME Session. Now I get the expected result after following the above steps.

[Sandy Armstrong (sanfordarmstrong)]

Of course I meant that I removed Network Manager from the GNOME Session for user "test1" in the above example.

[Sandy Armstrong (sanfordarmstrong)]

Well, I spoke to soon... it still crashes sometimes.

Crashes every time:
1. Log in as "test1" in an XNest session.
2. Start Tomboy.
3. Switch desktops in the main X Session before Tomboy appears in GNOME Panel.
4. Wait a bit (for Tomboy to start up, presumably).
5. Crash!

Crashes sometimes (can't reliably reproduce):
1. Log in as "test1" in an XNest session.
2. Do whatever?
3. Switch desktops, wait several minutes?
4. Crash! (randomly?)

Of course right now it's behaving nicely... undoubtedly waiting for me to submit this comment before introducing any new behaviors. :-)

[Vincent Untz (vuntz)]

FWIW, I've configured gdm to use xephyr instead of xnest and it's so much better I can't think of going back. Maybe the default gdm config should be changed?

[Rimas Kudelis (rq)]

You're right, configuring gdm to use Xephyr works around this problem. Thanks! :)

[Kevin McGuinness (kevin-mcguinness)]

Im not sure if this is related, but if I create a remote connection using tsclient over XDMCP and then switch workspaces or minimize the Xnest window, the connection is dropped.

Im using feisty x86 with desktop effects enabled and the i810 video driver

[Bryce Harrington (bryce)]

Yes, xephyr is to be preferred over xnest these days, since xnest doesn't support as many of the newer extensions. I think xnest may not be as well supported upstream anymore.

Reassigning to gdm as a wishlist item to switch from xnest to xephyr.

[Rolf Leggewie (r0lf)]

> Reassigning to gdm as a wishlist item to switch from xnest to xephyr.

I believe that is already the default. xephyr starts for me, not xnest. I have both installed. They are alternatively RECOMMENDS.

[Rolf Leggewie (r0lf)]

As I said, the wish is already granted in the current default AFAICT. Is there anything left to do before closing this bug?

[Chris Jones (cmsj)]

I'm no longer able to reproduce this with the current nested-login system.