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

[Thomas Fitzsimmons <fitzsim@fitzsim.org>]

Po Lu <luangruo@yahoo.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Thomas Fitzsimmons <fitzsim@fitzsim.org>
>>> Date: Wed, 07 Aug 2024 20:47:48 -0400
>>> 
>>> The attached patch fixes an issue reported on the mailing list [1].
>>> After quitting a remote "emacsclient -c" frame using C-x 5 0, the SSH
>>> session will hang on exit.  It is waiting for the X11 display connection
>>> to be closed, but Emacs never closes it.
>>> 
>>> I have been using this patch for a few months without issue, with the
>>> Lucid toolkit, running "emacsclient -c" over a remote X11 connection.
>>> 
>>> I just retested it on master (423c86cbde7b1ed1d42c7e21fef6e8be872857b0)
>>> with "./configure --with-x-toolkit=lucid" and it works for me.
>>> 
>>> I would like others who use remote X11 emacsclient to try the patch, to
>>> make sure it does not introduce crashes, error messages or warnings.  If
>>> it works for others, I can push the patch to master.
>>
>> Thanks, but "ssh -X" is not the only way of starting a remote client
>> session, is it?  How do we know closing the X connection is TRT in all
>> the cases, and cannot do any harm in some use cases other than yours?
>>
>> I'm also surprised that such a fundamental problem is raised only now,
>> when remote connections existed for decades.  Are you saying this is a
>> regression due to some recent change we installed?  If not, how come
>> this went undetected for so many years?
>>
>> Po Lu, any comments or suggestions?
>
> The issue that ought to be fixed is emacsclient's waiting for the
> display connection to be closed before exiting, as the automatic closure
> of connections without frames is expressly disabled on X toolkit builds,
> since closing a display connection is liable to induce crashes in the X
> toolkit.  Unless I misunderstand Thomas and it is ssh that is refusing
> to exit.

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