GNU bug report logs - #18375
24.4.50; Emacs hangs X session manager logout in certain cases

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 18375 in the body.
You can then email your comments to 18375 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Christoph Ruegge <chrueg <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.4.50; Emacs hangs X session manager logout in certain cases
Date: Sun, 31 Aug 2014 13:56:23 +0200

I experience a bug that can be produced as follows:

(1) start emacs -Q --daemon
(2) open an X frame
(3) close the frame
(4) logout.

The result is that the session manager (KDE's, in my case) logout hangs
since Emacs does not respond to the logout signal. The bug does not
occur if I logout before closing the frame, or open other frames and
interact with Emacs in any way that does not lead to no frame being open
at any given time (I can even close the first frame). Moreover, if I
logout before opening any frame, the logout does not hang, but the Emacs
process does not terminate.

I investigated a bit and think the reason has something to do with the
way the SM communication is tied to the first opened terminal. The
connection is opened at the end of x_term_init() when the first terminal
is opened (and is an X terminal). Once the last X frame is closed, the
terminal is closed as well. I don't know precisely why this causes the
bug, since the SM connection is supposed to be shut down in
x_delete_display(), but I am pretty sure that the bug happens if and
only if the first terminal has been closed.

Far as I see, the bug occurs only on non-GTK toolkits, since for GTK the
terminal is kept open to circumvent some GTK some bug, apparently.

If I may add, the current behaviour is rather weird to begin with. The
SM integration's purpose is to cleanly shutdown Emacs on logout, so it
should be tied to the entire process and not to a particular
terminal. There are essentially two scenarios for the Emacs daemon: it
can be run outside a desktop session (in which case there should be no
SM connection at all) or inside (in which case the connection should
last for the lifetime of the process). A cleaner approach would
therefore maybe be to seperate the SM connection from opening and
closing the terminal and have it done at startup if the user wishes,
maybe depending on a command line parameter, the presence of the DISPLAY
variable, or after user init depending on some elisp variable. The
connection itself could maybe be done through a dummy X terminal that is
kept open all the time. I tried simpy adding a call to
`x-open-connection' to startup.el, and this indeed fixes the bug (for
one of the use cases).

I'd be willing to try to write a patch for this, but as I'm not much of
a programmer and do not really understand the way Emacs handles
displays, it would likely not be up to quality standards.

Best regards



In GNU Emacs 24.4.50.16 (x86_64-unknown-linux-gnu)
 of 2014-08-30 on io
Windowing system distributor `The X.Org Foundation', version 11.0.11600000
System Description:	Arch Linux

Configured using:
 `configure --prefix=/home/cs/.local --with-x-toolkit=no --without-gconf
 --without-gsettings

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS NOTIFY ACL GNUTLS
LIBXML2 FREETYPE LIBOTF XFT ZLIB

Message #8 received at 18375 <at> debbugs.gnu.org (full text, mbox):

From: Christoph Ruegge <chrueg <at> gmail.com>
To: 18375 <at> debbugs.gnu.org
Subject: Re: 24.4.50; Emacs hangs X session manager logout in certain cases
Date: Mon, 1 Sep 2014 13:40:55 +0200

> I don't know precisely why this causes the
> bug, since the SM connection is supposed to be shut down in
> x_delete_display(), but I am pretty sure that the bug happens if and
> only if the first terminal has been closed.

Adding to this, I think the reason is that the call to x_session_close() in
x_delete_display() deletes the connection's FD, but does not actually tell the
SM to close. Adding a call to SmcCloseConnection() to x_session_close()
solves the hanging behaviour for me, but of course retains the weird behaviour
of Emacs not shutting down if the first terminal was closed.

Message #11 received at 18375 <at> debbugs.gnu.org (full text, mbox):

From: Christoph Ruegge <chrueg <at> gmail.com>
To: 18375 <at> debbugs.gnu.org
Subject: Re: 24.4.50; Emacs hangs X session manager logout in certain cases
Date: Mon, 1 Sep 2014 18:54:39 +0200

[Message part 1 (text/plain, inline)]

Ok, I wrote a patch that fixes the problem for me and implements the
behaviour I described earlier. Like I said, I don't really know what
I'm doing here, but maybe it can be helpful somehow ;-)

Best regards

[session-manager.patch (text/x-patch, attachment)]

Message #14 received at 18375 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Christoph Ruegge <chrueg <at> gmail.com>
Cc: 18375 <at> debbugs.gnu.org
Subject: Re: bug#18375: 24.4.50;
 Emacs hangs X session manager logout in certain cases
Date: Tue, 02 Sep 2014 14:25:39 -0400

> I investigated a bit and think the reason has something to do with the
> way the SM communication is tied to the first opened terminal.

Your analysis makes a lot of sense.

> If I may add, the current behaviour is rather weird to begin with. The
> SM integration's purpose is to cleanly shutdown Emacs on logout, so it
> should be tied to the entire process and not to a particular terminal.

Indeed, we have a problem there.  The `emacs --daemon' is not tied to
a particular display, so it should not shutdown in response to such
SM events.  OTOH, many users use "emacs --daemon" only for their
current session.  So I can't think of any way to resolve this, short of
making it a config var, like in your patch.

Looking at your patch, I like the idea of exposing the session-start/end
to Elisp, but I know too little about this area to really review
your patch.  Could someone else take a look at it?


        Stefan

Message #17 received at 18375 <at> debbugs.gnu.org (full text, mbox):

From: "Jan D." <jan.h.d <at> swipnet.se>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Christoph Ruegge <chrueg <at> gmail.com>,
 "18375 <at> debbugs.gnu.org" <18375 <at> debbugs.gnu.org>
Subject: Re: bug#18375: 24.4.50;
 Emacs hangs X session manager logout in certain cases
Date: Tue, 2 Sep 2014 22:56:02 +0200

Hi.

2 sep 2014 kl. 20:25 skrev Stefan Monnier <monnier <at> iro.umontreal.ca>:

>> I investigated a bit and think the reason has something to do with the
>> way the SM communication is tied to the first opened terminal.
> 
> Your analysis makes a lot of sense.
> 
>> If I may add, the current behaviour is rather weird to begin with. The
>> SM integration's purpose is to cleanly shutdown Emacs on logout, so it
>> should be tied to the entire process and not to a particular terminal.


No. The reason is to have Emacs restarted when the user logs in again.
Logout is no problem, the X connection will go away.

> Indeed, we have a problem there.  The `emacs --daemon' is not tied to
> a particular display, so it should not shutdown in response to such
> SM events.  OTOH, many users use "emacs --daemon" only for their
> current session.  So I can't think of any way to resolve this, short of
> making it a config var, like in your patch.
> 
> Looking at your patch, I like the idea of exposing the session-start/end
> to Elisp, but I know too little about this area to really review
> your patch.  Could someone else take a look at it?

Why not just skip all session manager interactions if run as a daemon?
You are technically not part of the session if the process can survive the session.

        Jan D. 

Message #20 received at 18375 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: "Jan D." <jan.h.d <at> swipnet.se>
Cc: Christoph Ruegge <chrueg <at> gmail.com>,
 "18375 <at> debbugs.gnu.org" <18375 <at> debbugs.gnu.org>
Subject: Re: bug#18375: 24.4.50;
 Emacs hangs X session manager logout in certain cases
Date: Tue, 02 Sep 2014 20:06:00 -0400

> Why not just skip all session manager interactions if run as a daemon?

I think that's what his patch does.


        Stefan

Message #23 received at 18375 <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Christoph Ruegge <chrueg <at> gmail.com>,
 "18375 <at> debbugs.gnu.org" <18375 <at> debbugs.gnu.org>
Subject: Re: bug#18375: 24.4.50;
 Emacs hangs X session manager logout in certain cases
Date: Wed, 3 Sep 2014 07:02:36 +0200

Hello.

3 sep 2014 kl. 02:06 skrev Stefan Monnier <monnier <at> iro.umontreal.ca>:

>> Why not just skip all session manager interactions if run as a daemon?
> 
> I think that's what his patch does.

It does not.  It doesn't do SM if inhibit-x-session-manager is non-nil, which is not the same thing, it requires the user to set it.
It also adds/changes code in several files and exposes things to lisp.

Disabling SM in case of deamon is two additional if-statements in xterm.c.

	Jan D.

Message #26 received at 18375 <at> debbugs.gnu.org (full text, mbox):

From: Christoph Ruegge <chrueg <at> gmail.com>
To: "Jan D." <jan.h.d <at> swipnet.se>
Cc: "18375 <at> debbugs.gnu.org" <18375 <at> debbugs.gnu.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#18375: 24.4.50; Emacs hangs X session manager logout in
 certain cases
Date: Wed, 3 Sep 2014 11:53:28 +0200

>>> If I may add, the current behaviour is rather weird to begin with. The
>>> SM integration's purpose is to cleanly shutdown Emacs on logout, so it
>>> should be tied to the entire process and not to a particular terminal.
>
>
> No. The reason is to have Emacs restarted when the user logs in again.
> Logout is no problem, the X connection will go away.


But that is not necessarily the only function of a session manager
(some SMs aren't even set to restart applications by default). They
also give applications the opportunity to query the user about unsaved
changes and such things. Now Emacs does not do that, but it's fairly
simple to do implement using `emacs-save-session-functions'.
Additionally, the only reason for me to log out is usually to restart
the computer, so Emacs will get killed anyway. Having the opportunity
to query about potential data loss may be useful.

That being said, I realize that my patch is rather intrusive and that
the more minimal solution of the daemon not using the SM at all is
better, especially since the daemon _can_ survive losing the X
connection (maybe in case of an X crash), which would lead to
unexpected behaviour in the next session. So one simply has to rely on
something like auto-save to prevent data loss.

Still, there's a corner case of the same bug occuring in non-daemon
mode, since it's technically possible to close the first terminal
after using e.g. "emacsclient -t", though that is likely a rather rare
situation.

Message #29 received at 18375 <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Christoph Ruegge <chrueg <at> gmail.com>
Cc: "18375 <at> debbugs.gnu.org" <18375 <at> debbugs.gnu.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#18375: 24.4.50;
 Emacs hangs X session manager logout in certain cases
Date: Wed, 3 Sep 2014 20:40:43 +0200

Hi.

3 sep 2014 kl. 11:53 skrev Christoph Ruegge <chrueg <at> gmail.com>:

> They
> also give applications the opportunity to query the user about unsaved
> changes and such things. Now Emacs does not do that, but it's fairly
> simple to do implement using `emacs-save-session-functions'.
> Additionally, the only reason for me to log out is usually to restart
> the computer, so Emacs will get killed anyway. Having the opportunity
> to query about potential data loss may be useful.

Save state is part of the session protocol.  But as daemon is supposed to survive the session, there is no saving of state needed when the session dies.

> That being said, I realize that my patch is rather intrusive and that
> the more minimal solution of the daemon not using the SM at all is
> better, especially since the daemon _can_ survive losing the X
> connection (maybe in case of an X crash), which would lead to
> unexpected behaviour in the next session. So one simply has to rely on
> something like auto-save to prevent data loss.
> 
> Still, there's a corner case of the same bug occuring in non-daemon
> mode, since it's technically possible to close the first terminal
> after using e.g. "emacsclient -t", though that is likely a rather rare
> situation.

The tests I done shows that the SM connection is not closed properly, ever.
So it is a bug.  On the other hand, X style session management is kind of deprecated.
You can see this in Fedora 20, where the whole desktop dies when emacsclient -c starts a new frame for a daemon outside the session.  I guess it looses it when a process outside the session attach to the session (or something like that).

I will fix the bug, and disable SM for daemon.

As for exposing SM to lisp, that might not be a bad idea, but it would be better to implement and expose the newer d-bus based SM than the old X based SM.   The latter will probably go away within a couple of years.  Gnome only has a compability layer for it on top of the d-bus SM.

	Jan D.

Message #32 received at 18375 <at> debbugs.gnu.org (full text, mbox):

From: Christoph Ruegge <chrueg <at> gmail.com>
To: Jan Djärv <jan.h.d <at> swipnet.se>
Cc: "18375 <at> debbugs.gnu.org" <18375 <at> debbugs.gnu.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#18375: 24.4.50; Emacs hangs X session manager logout in
 certain cases
Date: Wed, 3 Sep 2014 20:51:53 +0200

> The tests I done shows that the SM connection is not closed properly, ever.

Even if you add an SmcCloseConnection() call to x_session_close()?
Seemed to work for me.

> As for exposing SM to lisp, that might not be a bad idea, but it would be better to implement and expose the newer d-bus based SM than the old X based SM. The latter will probably go away within a couple of years. Gnome only has a compability layer for it on top of the d-bus SM.

That could maybe be done in pure Elisp, I suppose. Maybe I'll try that
if I have some spare time.

Message #37 received at 18375-done <at> debbugs.gnu.org (full text, mbox):

From: Jan Djärv <jan.h.d <at> swipnet.se>
To: Christoph Ruegge <chrueg <at> gmail.com>
Cc: "18375 <at> debbugs.gnu.org" <18375-done <at> debbugs.gnu.org>,
 Stefan Monnier <monnier <at> iro.umontreal.ca>
Subject: Re: bug#18375: 24.4.50;
 Emacs hangs X session manager logout in certain cases
Date: Thu, 4 Sep 2014 07:40:18 +0200

Bug fixed in trunk.

3 sep 2014 kl. 20:51 skrev Christoph Ruegge <chrueg <at> gmail.com>:

>> The tests I done shows that the SM connection is not closed properly, ever.
> 
> Even if you add an SmcCloseConnection() call to x_session_close()?
> Seemed to work for me.

Sure, if I change stuff it works, but not as it is.

	Jan D.

> 
>> As for exposing SM to lisp, that might not be a bad idea, but it would be better to implement and expose the newer d-bus based SM than the old X based SM. The latter will probably go away within a couple of years. Gnome only has a compability layer for it on top of the d-bus SM.
> 
> That could maybe be done in pure Elisp, I suppose. Maybe I'll try that
> if I have some spare time.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.