bug#43226: 28.0.50; Running Tramp tests on MS-Windows leaves zombie processes on the remote

bug#43226: 28.0.50; Running Tramp tests on MS-Windows leaves zombie processes on the remote

[Eli Zaretskii]

Running Tramp tests in test/lisp/net/tramp-tests.el leaves processes
on the remote system that don't get cleaned up.  For almost every test
in the test suite, when the test exits, 3 processes are left running
on the remote: 2 sshd's and one /bin/sh (and some tests leave more
than one such triplet of processes).  These processes must be cleaned
up by hand (by using "kill -HUP" on the remote system) in order not to
fill the system with zombie processes that eventually cause
connections to fail because the OS cannot start another shell process.


In GNU Emacs 28.0.50 (build 534, i686-pc-mingw32)
 of 2020-09-05 built on HOME-C4E4A596F7
Repository revision: 82b695faa3c501fc59b1972c43284d7e02510d7f
Repository branch: master
Windowing system distributor 'Microsoft Corp.', version 5.1.2600
System Description: Microsoft Windows XP Service Pack 3 (v5.1.0.2600)

Configured using:
 'configure -C --prefix=/d/usr --with-wide-int --with-modules
 --enable-checking=yes,glyphs 'CFLAGS=-O0 -gdwarf-4 -g3''

Configured features:
XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY W32NOTIFY ACL GNUTLS LIBXML2
HARFBUZZ ZLIB TOOLKIT_SCROLL_BARS MODULES THREADS JSON PDUMPER LCMS2

Important settings:
  value of $LANG: ENU
  locale-coding-system: cp1255

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message rmc puny dired dired-loaddefs
rfc822 mml easymenu mml-sec password-cache epa derived epg epg-config
gnus-util rmail rmail-loaddefs text-property-search time-date subr-x seq
byte-opt gv bytecomp byte-compile cconv mm-decode mm-bodies mm-encode
mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs cl-lib
sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type
mwheel dos-w32 ls-lisp disp-table term/w32-win w32-win w32-vars
term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode elisp-mode lisp-mode
prog-mode register page tab-bar menu-bar rfn-eshadow isearch timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
term/tty-colors frame minibuffer cl-generic cham georgian utf-8-lang
misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms
cp51932 hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese composite charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice loaddefs
button faces cus-face macroexp files text-properties overlay sha1 md5
base64 format env code-pages mule custom widget hashtable-print-readable
backquote threads w32notify w32 lcms2 multi-tty make-network-process
emacs)

Memory information:
((conses 16 51889 7931)
 (symbols 48 7147 1)
 (strings 16 18854 2377)
 (string-bytes 1 534939)
 (vectors 16 10868)
 (vector-slots 8 149128 10742)
 (floats 8 22 300)
 (intervals 40 246 76)
 (buffers 888 10))

bug#43226: Fwd: bug#26911: 25.2; eshell "cd .." doesn't work correctly with TRAMP

[Michael Albinus]

[-- Attachment #0: Type: message/rfc822, Size: 1115 bytes --]

From: Michael Albinus <michael.albinus@gmx.de>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 26911@debbugs.gnu.org,  mattiase@acm.org,  eggert@cs.ucla.edu, yegortimoshenko@gmail.com
Subject: Re: bug#26911: 25.2; eshell "cd .." doesn't work correctly with TRAMP
Date: Sat, 05 Sep 2020 19:36:34 +0200

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

>> Most of the tests start with (skip-unless (tramp--test-enabled)). This
>> defun calls tramp-cleanup-connection, which shall also kill all related
>> Tramp processes. Doesn't seem to work on MS Windows.
>
> AFAICS, tramp-cleanup-connection deletes the network connection
> processes, but is that supposed to make sure the other side of the
> connection exits cleanly?

It does at least when you're on GNU/Linux. What happens on MS Windows is
beyond my knowledge.

Perhaps I'll call process-send-eof prior killing the process?

>> Maybe we shall simply allow both messages, because the exact wording
>> doesn't matter. What about the appended patch?
>
> It fixes the problem, thanks.

Pushed to master.

Best regards, Michael.

bug#43226: Fwd: bug#26911: 25.2; eshell "cd .." doesn't work correctly with TRAMP

[Michael Albinus]

[-- Attachment #0: Type: message/rfc822, Size: 1173 bytes --]

From: Eli Zaretskii <eliz@gnu.org>
To: Michael Albinus <michael.albinus@gmx.de>
Cc: 26911@debbugs.gnu.org, mattiase@acm.org, eggert@cs.ucla.edu, yegortimoshenko@gmail.com
Subject: Re: bug#26911: 25.2; eshell "cd .." doesn't work correctly with TRAMP
Date: Sat, 05 Sep 2020 20:56:00 +0300

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: 26911@debbugs.gnu.org,  mattiase@acm.org,  eggert@cs.ucla.edu,
>   yegortimoshenko@gmail.com
> Date: Sat, 05 Sep 2020 19:36:34 +0200
>
> > AFAICS, tramp-cleanup-connection deletes the network connection
> > processes, but is that supposed to make sure the other side of the
> > connection exits cleanly?
>
> It does at least when you're on GNU/Linux. What happens on MS Windows is
> beyond my knowledge.

Indeed, it's strange that the result should depend on the local
system, since the commands sent to the remote are the same in boths
cases, I'd imagine.

> Perhaps I'll call process-send-eof prior killing the process?

If you show me a patch, I can try it.  But let's continue discussing
this in the bug I filed, bug#43226.

Thanks.

bug#43226: 28.0.50; Running Tramp tests on MS-Windows leaves zombie processes on the remote

[Michael Albinus]

Hi Eli,

>> > AFAICS, tramp-cleanup-connection deletes the network connection
>> > processes, but is that supposed to make sure the other side of the
>> > connection exits cleanly?
>>
>> It does at least when you're on GNU/Linux. What happens on MS Windows is
>> beyond my knowledge.
>
> Indeed, it's strange that the result should depend on the local
> system, since the commands sent to the remote are the same in boths
> cases, I'd imagine.

Maybe it has nothing to do with the local OS but with the local
program? On GNU/Linux we use ssh, on MS Windows we use plink.

Best regards, Michael.

bug#43226: 28.0.50; Running Tramp tests on MS-Windows leaves zombie processes on the remote

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Date: Sat, 05 Sep 2020 21:16:25 +0200
> 
> > Indeed, it's strange that the result should depend on the local
> > system, since the commands sent to the remote are the same in boths
> > cases, I'd imagine.
> 
> Maybe it has nothing to do with the local OS but with the local
> program? On GNU/Linux we use ssh, on MS Windows we use plink.

Maybe so, but what do we expect from ssh/plink which should happen
when the connection closes, that might not happen with plink?

E.g., if I run 'plink ... "cat foo"', the processes created on the
remote disappear immediately as soon as 'cat' finishes its job.  Same
if I log in and type Ctrl-D, or just close the window where plink runs
interactively.  What is different about the connections made by Tramp
or the test suite?

bug#43226: 28.0.50; Running Tramp tests on MS-Windows leaves zombie processes on the remote

[Michael Albinus]

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

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

>> Maybe it has nothing to do with the local OS but with the local
>> program? On GNU/Linux we use ssh, on MS Windows we use plink.
>
> Maybe so, but what do we expect from ssh/plink which should happen
> when the connection closes, that might not happen with plink?
>
> E.g., if I run 'plink ... "cat foo"', the processes created on the
> remote disappear immediately as soon as 'cat' finishes its job.  Same
> if I log in and type Ctrl-D, or just close the window where plink runs
> interactively.  What is different about the connections made by Tramp
> or the test suite?

The difference is, that in your example the remote process finishes. In
Tramp, the local ssh or plink process is killed.

Does the appended patch makes a difference?

Best regards, Michael.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 974 bytes --]

*** /tmp/ediffJtV3Wc	2020-09-06 10:45:52.531153450 +0200
--- /home/albinus/src/tramp/lisp/tramp-cmds.el	2020-09-06 10:44:50.956836536 +0200
***************
*** 122,127 ****
--- 122,128 ----
  		 (or (not keep-processes)
  		     (eq key (tramp-get-process vec))))
  	(tramp-flush-connection-properties key)
+ 	(process-send-eof key)
  	(delete-process key)))

      ;; Remove buffers.
***************
*** 186,192 ****

    ;; Remove processes and buffers.
    (dolist (name (tramp-list-tramp-buffers))
!     (when (processp (get-buffer-process name)) (delete-process name))
      (when (bufferp (get-buffer name)) (kill-buffer name)))

    ;; The end.
--- 187,195 ----

    ;; Remove processes and buffers.
    (dolist (name (tramp-list-tramp-buffers))
!     (when (processp (get-buffer-process name))
!       (process-send-eof name)
!       (delete-process name))
      (when (bufferp (get-buffer name)) (kill-buffer name)))

    ;; The end.

bug#43226: 28.0.50; Running Tramp tests on MS-Windows leaves zombie processes on the remote

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: 43226@debbugs.gnu.org
> Date: Sun, 06 Sep 2020 10:49:51 +0200
> 
> Does the appended patch makes a difference?

I'm afraid it doesn't.

Just to be sure I test this correctly: after installing the change and
compiling tramp-cmds.el, I run the test tramp-test30-make-process
twice.  What I see after the first run is that 2 'cat' processes (each
one with 2 sshd) and one /bin/sh process (with 2 sshd processes of its
own) are left behind.  After the second run, I see 4 'cat' processes
(each one with 2 sshd) and the same single /bin/sh process with its 2
sshd processes.  Thus my conclusion is that sending EOF to the
processes doesn't help.

Thanks.

bug#43226: 28.0.50; Running Tramp tests on MS-Windows leaves zombie processes on the remote

[Michael Albinus]

Eli Zaretskii <eliz@gnu.org> writes:

Hi Eli,

> Just to be sure I test this correctly: after installing the change and
> compiling tramp-cmds.el, I run the test tramp-test30-make-process
> twice.  What I see after the first run is that 2 'cat' processes (each
> one with 2 sshd) and one /bin/sh process (with 2 sshd processes of its
> own) are left behind.  After the second run, I see 4 'cat' processes
> (each one with 2 sshd) and the same single /bin/sh process with its 2
> sshd processes.  Thus my conclusion is that sending EOF to the
> processes doesn't help.

Yes, this is right. I have no idea how else we could kill the remote
processes, prior killing the local plink.

We could send the "exit" command. But the idea of
tramp-cleanup-connection is to unblock a remote connection. Sending just
another command doesn't sound like TRT.

> Thanks.

Best regards, Michael.

bug#43226: 28.0.50; Running Tramp tests on MS-Windows leaves zombie processes on the remote

[Eli Zaretskii]

> From: Michael Albinus <michael.albinus@gmx.de>
> Cc: 43226@debbugs.gnu.org
> Date: Sun, 06 Sep 2020 17:54:51 +0200
> 
> > Just to be sure I test this correctly: after installing the change and
> > compiling tramp-cmds.el, I run the test tramp-test30-make-process
> > twice.  What I see after the first run is that 2 'cat' processes (each
> > one with 2 sshd) and one /bin/sh process (with 2 sshd processes of its
> > own) are left behind.  After the second run, I see 4 'cat' processes
> > (each one with 2 sshd) and the same single /bin/sh process with its 2
> > sshd processes.  Thus my conclusion is that sending EOF to the
> > processes doesn't help.
> 
> Yes, this is right. I have no idea how else we could kill the remote
> processes, prior killing the local plink.

I think at this point we need some expert on TCP connections to chime
in.  AFAIU, your hypothesis is that the way we kill network processes
on MS-Windows somehow fails to send SIGHUP to the other end of the
connection?  I'm not sure how this could happen, since I think Windows
sockets are a more-or-less faithful emulation of sockets.

Or maybe you (or someone else) could describe in detail how the
deletion of the network-connection process is supposed to shut down
the processes on the other end of the connection?

bug#43226: 28.0.50; Running Tramp tests on MS-Windows leaves zombie processes on the remote

[Henrik Ahlgren]

Could this be related to this rather annoying issue with Magit on
Windows?

https://github.com/magit/magit/issues/3624

BTW, the hang happens not only with Plink, but also with ssh.exe (the
built-in OpenSSH in Windows).

bug#43226: 28.0.50; Running Tramp tests on MS-Windows leaves zombie processes on the remote

[Eli Zaretskii]

> From: Henrik Ahlgren <pablo@seestieto.com>
> Cc: 43226@debbugs.gnu.org
> Date: Tue, 25 Oct 2022 12:39:43 +0300
> 
> Could this be related to this rather annoying issue with Magit on
> Windows?
> 
> https://github.com/magit/magit/issues/3624
> 
> BTW, the hang happens not only with Plink, but also with ssh.exe (the
> built-in OpenSSH in Windows).

I don't know.  If this is about remote Git processes, then
process-send-eof sends EOF via the network connection, doesn't it?  If
so, the network-connection implementation of process-send-eof works on
MS-Windows like it works on any other system: we call 'shutdown'.

If in this scenario we try to send EOF to a local process running on
Windows, then we close the file descriptor, like we do on other
systems.  Why would that not work?

Bottom line: I have no idea what's going on there, sorry.

bug#43226: 28.0.50; Running Tramp tests on MS-Windows leaves zombie processes on the remote

[Henrik Ahlgren]

Eli Zaretskii <eliz@gnu.org> writes:

> I don't know.  If this is about remote Git processes, then
> process-send-eof sends EOF via the network connection, doesn't it?  If
> so, the network-connection implementation of process-send-eof works on
> MS-Windows like it works on any other system: we call 'shutdown'.

Indeed – when you work with remote git working trees over Tramp and want
to stage individual hunks from the Magit interface, it will run "git
apply -" (with a bunch of extra parameters) and attempts to send the
patches over to standard in. This, unlike staging a whole file (which
simply does "git add <file>"), hangs your whole Emacs session until you
hit C-g.

Consider this example that seems to work fine (no cmdproxy involved):

(let ((start-file-process "eoftest" (get-buffer-create "*eoftest*")
			  "ssh" "<hostname>" "cat"))
  (sit-for 10)
  (process-send-string sshz "foo")
  (sit-for 5)
  (process-send-eof sshz))

vs this that hangs, leaving cat running forever:

(let ((default-directory "/sshx:<hostname>:/home/my/git/dir")
      (sshz start-file-process "eoftest" (get-buffer-create "*eoftest*")
			  "cat"))
  (sit-for 10)
  (process-send-string sshz "foo")
  (sit-for 5)
  (process-send-eof sshz))

The cat process does not even seem to receive any input ("foo") I trace
it in the remote machine.

ps. I wonder why my emails are not appearing in debbugs?

bug#43226: 28.0.50; Running Tramp tests on MS-Windows leaves zombie processes on the remote

[Michael Albinus]

Henrik Ahlgren <pablo@seestieto.com> writes:

Hi Henrik,

> ps. I wonder why my emails are not appearing in debbugs?

They are there, after I did approve your messages for the debbugs ML. I
do it one or two times a day, other people do also, but we're not a 24/7 service.

Best regards, Michael.

bug#43226: 28.0.50; Running Tramp tests on MS-Windows leaves zombie processes on the remote

[Eli Zaretskii]

> From: Henrik Ahlgren <pablo@seestieto.com>
> Cc: 43226@debbugs.gnu.org
> Date: Tue, 25 Oct 2022 16:56:37 +0300
> 
> Consider this example that seems to work fine (no cmdproxy involved):
> 
> (let ((start-file-process "eoftest" (get-buffer-create "*eoftest*")
> 			  "ssh" "<hostname>" "cat"))
>   (sit-for 10)
>   (process-send-string sshz "foo")
>   (sit-for 5)
>   (process-send-eof sshz))
> 
> vs this that hangs, leaving cat running forever:
> 
> (let ((default-directory "/sshx:<hostname>:/home/my/git/dir")
>       (sshz start-file-process "eoftest" (get-buffer-create "*eoftest*")
> 			  "cat"))
>   (sit-for 10)
>   (process-send-string sshz "foo")
>   (sit-for 5)
>   (process-send-eof sshz))
> 
> The cat process does not even seem to receive any input ("foo") I trace
> it in the remote machine.

Maybe Michael (CC'ed) can explain how this is supposed to work,
because I don't think I understand.  The actual process run by Emacs
is ssh, not cat, so how is EOF supposed to get to the remote "cat"?

> ps. I wonder why my emails are not appearing in debbugs?

No clue.  Fortunately, Michael also knows about debbugs much more than
I do.

bug#43226: 28.0.50; Running Tramp tests on MS-Windows leaves zombie processes on the remote

[Henrik Ahlgren]

Eli Zaretskii <eliz@gnu.org> writes:

> Maybe Michael (CC'ed) can explain how this is supposed to work,
> because I don't think I understand.  The actual process run by Emacs
> is ssh, not cat, so how is EOF supposed to get to the remote "cat"?

Not exactly sure, but clearly there is some difference between POSIX
platforms and Windows on how process-send-eof works in certain
situations when dealing with Tramp remote connections, and this breaks
some functionality of Magit, not just Tramp's own tests. 

In my test I just used cat to emulate "git apply -" to trace what it
receives from the standard input.

This issue is documented on the FAQ section of the Magit manual:

  A.2.13 I am unable to stage when using Tramp from MS Windows
  ------------------------------------------------------------

  Magit may be unable to stage (or otherwise apply) individual hunks when
  you are connected to remote machine using Tramp and the local machine
  uses MS Windows.

     There appears to be a problem with ‘process-send-eof’ in this
  scenario, as mentioned at the end of ‘tramp-tests.el’.  I have contacted
  the Tramp maintainer about this.  For now this unfortunately means that
  it just doesn’t work and we cannot do anything about it.  If you have
  more information, then please comment on
  <https://github.com/magit/magit/issues/3624>.

After some debugging I figured out that by simply adding
(process-send-string process "\004") in magic-process.el before (maybe
even instead?) of process-send-eof, it works perfectly well. Maybe it's
a valid workaround, or even the proper fix, but clearly there is some
point of having a separate function for sending EOF.

In the C implementation of process-send-eof (Emacs 27.1), it seems to only
send EOF if the process has pty_flag set:

  if (XPROCESS (proc)->pty_flag)
    send_process (proc, "\004", 1, Qnil);

I think this could be the reason: after all I believe PTYs are a fairly
recent feature in Windows and Emacs does not support it yet? OTOH, this
function seems to work when running ssh directly from start-file-process
which apparently doesn't use cmdproxy.exe. Anyway, I have no means of
compiling Emacs on Windows to debug the C source to see if pty_flag is
set on the non-cmdproxy.exe case.

bug#43226: 28.0.50; Running Tramp tests on MS-Windows leaves zombie processes on the remote

[Eli Zaretskii]

> From: Henrik Ahlgren <pablo@seestieto.com>
> Cc: Michael Albinus <michael.albinus@gmx.de>, 43226@debbugs.gnu.org
> Date: Wed, 26 Oct 2022 14:34:09 +0300
> 
> This issue is documented on the FAQ section of the Magit manual:
> 
>   A.2.13 I am unable to stage when using Tramp from MS Windows
>   ------------------------------------------------------------
> 
>   Magit may be unable to stage (or otherwise apply) individual hunks when
>   you are connected to remote machine using Tramp and the local machine
>   uses MS Windows.
> 
>      There appears to be a problem with ‘process-send-eof’ in this
>   scenario, as mentioned at the end of ‘tramp-tests.el’.  I have contacted
>   the Tramp maintainer about this.  For now this unfortunately means that
>   it just doesn’t work and we cannot do anything about it.  If you have
>   more information, then please comment on
>   <https://github.com/magit/magit/issues/3624>.

This doesn't really add any useful information.

> After some debugging I figured out that by simply adding
> (process-send-string process "\004") in magic-process.el before (maybe
> even instead?) of process-send-eof, it works perfectly well. Maybe it's
> a valid workaround, or even the proper fix, but clearly there is some
> point of having a separate function for sending EOF.
> 
> In the C implementation of process-send-eof (Emacs 27.1), it seems to only
> send EOF if the process has pty_flag set:
> 
>   if (XPROCESS (proc)->pty_flag)
>     send_process (proc, "\004", 1, Qnil);
> 
> I think this could be the reason: after all I believe PTYs are a fairly
> recent feature in Windows and Emacs does not support it yet?

Emacs doesn't (and probably will not) support the Windows
Pseudo-Console because it falls short of what Emacs needs: it doesn't
allow to send stuff in arbitrary encoding via this channel.  I filed a
bug report with the developers many moons ago, but their response was
that it will probably never fixed.  So you can only talk to a program
that uses the current system codepage, which is useless for Emacs.

So the ->pty_flag case is not for Windows.  And even if we did try
using it, it wouldn't have worked for local processes, because Ctrl-D
is NOT the EOF character on Windows; it's Ctrl-Z, and then only if the
sub-process does text-mode reads (in binary mode, there's no way to
send EOF to a subprocess, only kill it).

bug#43226: 28.0.50; Running Tramp tests on MS-Windows leaves zombie processes on the remote

[HA]

Eli Zaretskii <eliz@gnu.org> writes:

> So the ->pty_flag case is not for Windows.  And even if we did try
> using it, it wouldn't have worked for local processes, because Ctrl-D
> is NOT the EOF character on Windows; it's Ctrl-Z, and then only if the
> sub-process does text-mode reads (in binary mode, there's no way to
> send EOF to a subprocess, only kill it).

You're right – when trying the test case with just ssh in Emacs 28 on
Windows, process-send-eof successfully terminates the remote cat
process, it just never receives the actual Ctrl-D. (Verified this by
stracing the remote cat process.)

The test case where I call start-file-process with default-directory
pointing to a remote directory ("/sshx:...") and run simply "cat"
behaves differently in that it runs cmdproxy.exe instead of ssh.exe
directly, uses the -t option twice to force creation of PTYs on the
remote end, and uses -o RemoteCommand="/bin/sh -i" for interactive
shell. It does not seem to receive any input from Emacs, and stays
running.

Same things also happens if I run the test with "ssh -t -t" so
apparently somehow pseudo terminals on the remote end causes issues
here.

The normal "ssh" method (without -x) does not seem to be able to connect
at all on my Windows system for whatever reason, so I can't comment if
works any better.

Interestingly, similar test on Emacs 27.1 on GNU/Linux
receives the input but the cat process also stays running there, so
not sure if process-send-eof does the right thing even here.

(let* ((default-directory "/sshx:happy:/tmp")
      (sshz (start-file-process "eoftest" (get-buffer-create "*eoftest*") "cat")))
  (list-processes)
  (sit-for 10) ; Run strace -p $(pgrep cat) on remote
  (process-send-string sshz "foo")
  (process-send-eof sshz))

strace: Process 18005 attached
read(0, "foo", 131072)                  = 3
write(1, "foo", 3)                      = 3
read(0, 

bug#43226: 28.0.50; Running Tramp tests on MS-Windows leaves zombie processes on the remote

[Michael Albinus]

HA <pablo@seestieto.com> writes:

Hi,

> You're right – when trying the test case with just ssh in Emacs 28 on
> Windows, process-send-eof successfully terminates the remote cat
> process, it just never receives the actual Ctrl-D. (Verified this by
> stracing the remote cat process.)

Likely, it terminates the local ssh process, which kills the remote cat
process as side effect.

> The test case where I call start-file-process with default-directory
> pointing to a remote directory ("/sshx:...") and run simply "cat"
> behaves differently in that it runs cmdproxy.exe instead of ssh.exe
> directly, uses the -t option twice to force creation of PTYs on the
> remote end, and uses -o RemoteCommand="/bin/sh -i" for interactive
> shell. It does not seem to receive any input from Emacs, and stays
> running.

Yes.

> Same things also happens if I run the test with "ssh -t -t" so
> apparently somehow pseudo terminals on the remote end causes issues
> here.

Perhaps.

> The normal "ssh" method (without -x) does not seem to be able to connect
> at all on my Windows system for whatever reason, so I can't comment if
> works any better.

Right. And I have no explanation for this.

> Interestingly, similar test on Emacs 27.1 on GNU/Linux
> receives the input but the cat process also stays running there, so
> not sure if process-send-eof does the right thing even here.
>
> (let* ((default-directory "/sshx:happy:/tmp")
>       (sshz (start-file-process "eoftest" (get-buffer-create "*eoftest*") "cat")))
>   (list-processes)
>   (sit-for 10) ; Run strace -p $(pgrep cat) on remote
>   (process-send-string sshz "foo")
>   (process-send-eof sshz))
>
> strace: Process 18005 attached
> read(0, "foo", 131072)                  = 3
> write(1, "foo", 3)                      = 3
> read(0, 

I can reproduce it here with Emacs 29. However, if you replace
process-send-eof by kill-process it works. But I don't know whether this
is an acceptable solution.

Another idea is to use EscapeChar. Tramp calls " ssh -q -e none -t -t ...".
If we use an EscapeChar, like the default "~", we could send "\n~."
(newline escape period) in order to disconnect, imitating eof. But I
haven't tested it. And there might be collateral damages when sending
binary data.

Best regards, Michael.