GNOME Bugzilla – Bug 375317
Login Window: The remote X session loc...
Last modified: 2006-12-23 15:15:17 UTC
What were you doing when the application crashed? The remote X session locks the screen when local user locks his screen. Funny bug :-D Distribution: Ubuntu 6.10 (edgy) Gnome Release: 2.16.1 2006-10-02 (Ubuntu) BugBuddy Version: 2.16.0
I'm not sure this is a GDM bug. It sounds like a lockscreen problem? What lock screen program are you using? Please explain in more detail what you do to create the problem?
I'm using gnome-screensaver. I agree with you, is probably a gnome-screensaver bug. this happends: there are two users: A local login B remote XDMCP login When the user A locks his screen, the remote session screen locks. To reproduce this bug, try to login using XDMCP and locks the local session. Thanks
The only way this could happen is if both sessions are using the same dbus session bus address. And I can't see how that would be... Does ubuntu add patches that may do this? Can you see if the output of "env|grep DBUS" is the same in both sessions? I'm going to move this back to GDM because that is where the dbus session bus is created.
No, the problem is not here... addresses looks differents (and the problem is still here): "env | grep DBUS" from the local console... DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-ro8Ysb6TFE,guid=61397845135b1bfeac676ea2ec81ee00 From the remote console istance... DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-El0J9bFquz,guid=c4f77d4561a7e05e10a9c9a455ae7d00
I'm still not sure that this is a GDM problem. Note that dbus-launch integration for starting the session is not integrated into GDM CVS head. Each distro integrates the dbus-launch mechanisms into the startup scripts as appropriate for the distro. This may be a problem with the way dbus-launch is setup on your distro. Not sure, but just to let you know that GDM doesn't contain any logic to start dbus.
So, dbus is working well. Let me try to follow the events... When i close my laptop, the switch closes and "someone A" launch a signal on the dbus. The remote "gnomescreensaver" receive this signal and locks the screen. I'm not a DBUS specialist at all but the problem is: 1) in gnomescreensaver, that don't control from who arrives the lock signal. 2) from "someone A", (could be ACPI) that don't send a correct formatted signal.
3) or: something else i can't imagine :-)
Ah, you didn't mention that you were closing a laptop at the time. I thought that you were clicking the "Lock Screen" menu item or something. In this case, it is gnome-power-manager that is locking the screen. We are working on the infrastructure (console-kit etc) to be able to fix this properly. Basically, g-p-m should not be controlling the hardware when run from a XDMCP session.
*** This bug has been marked as a duplicate of 348218 ***