bug#72517: 31.0.50; [PATCH] Close X connection upon deletion of last emacsclient frame

[Thomas Fitzsimmons <fitzsim@fitzsim.org>]

[-- Attachment #1: Type: text/plain, Size: 2527 bytes --]

Po Lu <luangruo@yahoo.com> writes:

> Thomas Fitzsimmons <fitzsim@fitzsim.org> writes:
>
>> Thank you for taking a look at this.
>>
>> It is indeed SSH that is refusing to exit.
>>
>> i.e., after exiting the emacsclient frame, I am returned to the remote
>> SSH shell.  Pressing control-d in that shell does not return me back to
>> my local shell (the shell from which I SSH'd).  I have to press
>> control-c and then I am returned back to my local shell.
>>
>> Nothing emacs-related is hanging; the emacs daemon continues running,
>> and I can re-SSH and re-run emacsclient.  So the control-c to exit the
>> SSH session does not seem to destabilize the emacs daemon.  (However, I
>> suspect the control-c is severing the X display connection which seems
>> less safe and potentially more subject to race conditions than Emacs
>> itself closing the X connection.)
>>
>> There are so many use cases for emacsclient that any patch seems risky,
>> which is why I filed this bug report with something that works for me.
>>
>> If there is a comprehensive set of emacsclient connection/disconnection
>> tests, and/or any verbosity/debugging options that might help, then I
>> can run them by hand on my setup.  I did try:
>>
>> 1. local X11 "emacsclient -c -s test"
>> 2. local X11 "emacsclient -nw -s test"
>> 3. remote (over ssh -X) "emacsclient -c -s test"
>> 4. remote (over ssh -X) "emacsclient -nw -s test"
>>
>> against "emacs -Q --fg-daemon=test".  In each case, with this patch, the
>> key sequence C-x 5 0 exits the frame without issue, and (for tests 3 and
>> 4) C-d exits the SSH session (returns me to my local shell) without my
>> having to press C-c.  Without my patch, test 3 does result in SSH
>> refusing to exit.
>>
>> And, even with my patch, for test case 3, using C-x C-c to delete the
>> frame still results in SSH refusing to exit.  (It would be nice to fix
>> this case too, but I always use C-x 5 0, so I wanted to start by trying
>> to fix it.)
>>
>> Thomas
>
> I suggest configuring Emacs with --with-x-toolkit=no (as is recommended
> for users who connect to remote display servers to begin with).

That works, both C-x C-c and C-x 5 0 exit the emacsclient frame, and SSH
does not hang/refuse to exit in either case.  I will use
--with-x-toolkit=no from now on, thank you!

Somehow I missed that recommendation (maybe you can point me to it?).  I
have always avoided GTK for "emacsclient reasons" but I thought Lucid
would be OK.  Can I add something like the attached to etc/PROBLEMS?

Thanks,
Thomas


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: emacsclient-ssh-hang-problems.patch --]
[-- Type: text/x-diff, Size: 1117 bytes --]

diff --git a/etc/PROBLEMS b/etc/PROBLEMS
index 7d7c9ab5f27..d0d529adb3c 100644
--- a/etc/PROBLEMS
+++ b/etc/PROBLEMS
@@ -178,6 +178,21 @@ The relevant bug report is here:
 A workaround is to set XLIB_SKIP_ARGB_VISUALS=1 in the environment
 before starting Emacs, or run Emacs as root.
 
+** emacsclient -c causes an ssh -X session to hang on exit.
+
+When Emacs is configured with an X toolkit, for example,
+--with-x-toolkit=lucid, and emacsclient is run over an "ssh -X"
+connection, deleting the emacsclient frame (via C-x 5 0 or C-x C-c) can
+leave the X display connection open.
+
+The symptom is that after you delete the "emacsclient -c" frame, and
+then attempt to exit ssh (with C-d, or "exit"), ssh will hang before
+returning you to the local shell.  You will have to press C-c (to sever
+the X connection) before ssh returns you to your local shell (that is,
+the shell in which you invoked "ssh -X").
+
+To avoid this issue configure Emacs with --with-x-toolkit=no.
+
 ** Emacs built with xwidgets aborts when displaying WebKit xwidgets
 
 This happens, for example, when 'M-x xwidget-webkit-browse-url'