[7890] in athena10
[Debathena] #979: gdm's g-s-d sticks around after login
daemon@ATHENA.MIT.EDU (Debathena Trac)
Tue Jul 19 08:07:29 2011
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
From: "Debathena Trac" <debathena@MIT.EDU>
Cc: debathena@mit.edu
To: jdreed@mit.edu
Date: Tue, 19 Jul 2011 12:07:20 -0000
Reply-To:
Message-ID: <043.8e0a6b7bb26bfd3ea3ebccfef41bdb4c@mit.edu>
Content-Transfer-Encoding: 8bit
#979: gdm's g-s-d sticks around after login--------------------+-------------------------------------------------------
Reporter: jdreed | Owner:
Type: defect | Status: new
Priority: high | Milestone: Natty Release
Component: -- | Keywords:
See_also: |
--------------------+------------------------------------------------------- From #850:
The first time a user logs in, using the Athena default sesion, LP:649809
is triggered (gdm's g-s-d sticks around and conflicts with the users').
Subsequent logins generally work, except when they don't. Logging in with
"Ubuntu Classic" sometimes works and sometimes doesn't. I... don't have a
good solution here. And of course the user can't kill gdm's g-s-d. My
current bad idea involves an Xsession.d that sleeps for up to 10 seconds,
checking ps to see if gdm's g-s-d is dead.
Zephyr discussion suggests upstream is also having problems reproducing
this on anything but Ubuntu, and that it primarily affects VMs, but does
manifest on real hardware. I suggest the following stupid workaround:
{{{
Index: debathena-branding
===================================================================
--- debathena-branding (revision 25221)
+++ debathena-branding (working copy)
@@ -109,6 +109,7 @@
# Here on a Stop signal from the session manager.
def sm_on_Stop(self):
+ subprocess.call(["/usr/bin/pkill", "-f", "gnome-settings-
daemon"])
gtk.main_quit()
def main(options):
}}}
-- Ticket URL: <http://debathena.mit.edu/trac/ticket/979>Debathena <http://debathena.mit.edu/>MIT Debathena Project
