* bug#43226: 28.0.50; Running Tramp tests on MS-Windows leaves zombie processes on the remote @ 2020-09-05 16:38 Eli Zaretskii 2020-09-05 19:04 ` bug#43226: Fwd: bug#26911: 25.2; eshell "cd .." doesn't work correctly with TRAMP Michael Albinus 2020-09-05 19:04 ` Michael Albinus 0 siblings, 2 replies; 18+ messages in thread From: Eli Zaretskii @ 2020-09-05 16:38 UTC (permalink / raw) To: 43226 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)) ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#43226: Fwd: bug#26911: 25.2; eshell "cd .." doesn't work correctly with TRAMP 2020-09-05 16:38 bug#43226: 28.0.50; Running Tramp tests on MS-Windows leaves zombie processes on the remote Eli Zaretskii @ 2020-09-05 19:04 ` Michael Albinus 2020-09-05 19:04 ` Michael Albinus 1 sibling, 0 replies; 18+ messages in thread From: Michael Albinus @ 2020-09-05 19:04 UTC (permalink / raw) To: 43226 [-- 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#43226: Fwd: bug#26911: 25.2; eshell "cd .." doesn't work correctly with TRAMP 2020-09-05 16:38 bug#43226: 28.0.50; Running Tramp tests on MS-Windows leaves zombie processes on the remote Eli Zaretskii 2020-09-05 19:04 ` bug#43226: Fwd: bug#26911: 25.2; eshell "cd .." doesn't work correctly with TRAMP Michael Albinus @ 2020-09-05 19:04 ` Michael Albinus 2020-09-05 19:16 ` bug#43226: 28.0.50; Running Tramp tests on MS-Windows leaves zombie processes on the remote Michael Albinus 1 sibling, 1 reply; 18+ messages in thread From: Michael Albinus @ 2020-09-05 19:04 UTC (permalink / raw) To: 43226 [-- 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#43226: 28.0.50; Running Tramp tests on MS-Windows leaves zombie processes on the remote 2020-09-05 19:04 ` Michael Albinus @ 2020-09-05 19:16 ` Michael Albinus 2020-09-05 19:25 ` Eli Zaretskii 0 siblings, 1 reply; 18+ messages in thread From: Michael Albinus @ 2020-09-05 19:16 UTC (permalink / raw) To: 43226 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#43226: 28.0.50; Running Tramp tests on MS-Windows leaves zombie processes on the remote 2020-09-05 19:16 ` bug#43226: 28.0.50; Running Tramp tests on MS-Windows leaves zombie processes on the remote Michael Albinus @ 2020-09-05 19:25 ` Eli Zaretskii 2020-09-06 8:49 ` Michael Albinus 0 siblings, 1 reply; 18+ messages in thread From: Eli Zaretskii @ 2020-09-05 19:25 UTC (permalink / raw) To: Michael Albinus; +Cc: 43226 > 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? ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#43226: 28.0.50; Running Tramp tests on MS-Windows leaves zombie processes on the remote 2020-09-05 19:25 ` Eli Zaretskii @ 2020-09-06 8:49 ` Michael Albinus 2020-09-06 15:14 ` Eli Zaretskii 0 siblings, 1 reply; 18+ messages in thread From: Michael Albinus @ 2020-09-06 8:49 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 43226 [-- 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#43226: 28.0.50; Running Tramp tests on MS-Windows leaves zombie processes on the remote 2020-09-06 8:49 ` Michael Albinus @ 2020-09-06 15:14 ` Eli Zaretskii 2020-09-06 15:54 ` Michael Albinus 0 siblings, 1 reply; 18+ messages in thread From: Eli Zaretskii @ 2020-09-06 15:14 UTC (permalink / raw) To: Michael Albinus; +Cc: 43226 > 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#43226: 28.0.50; Running Tramp tests on MS-Windows leaves zombie processes on the remote 2020-09-06 15:14 ` Eli Zaretskii @ 2020-09-06 15:54 ` Michael Albinus 2020-09-06 16:07 ` Eli Zaretskii 0 siblings, 1 reply; 18+ messages in thread From: Michael Albinus @ 2020-09-06 15:54 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 43226 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#43226: 28.0.50; Running Tramp tests on MS-Windows leaves zombie processes on the remote 2020-09-06 15:54 ` Michael Albinus @ 2020-09-06 16:07 ` Eli Zaretskii 2022-10-25 9:39 ` Henrik Ahlgren 0 siblings, 1 reply; 18+ messages in thread From: Eli Zaretskii @ 2020-09-06 16:07 UTC (permalink / raw) To: Michael Albinus; +Cc: 43226 > 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? ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#43226: 28.0.50; Running Tramp tests on MS-Windows leaves zombie processes on the remote 2020-09-06 16:07 ` Eli Zaretskii @ 2022-10-25 9:39 ` Henrik Ahlgren 2022-10-25 11:26 ` Eli Zaretskii 0 siblings, 1 reply; 18+ messages in thread From: Henrik Ahlgren @ 2022-10-25 9:39 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 43226 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). ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#43226: 28.0.50; Running Tramp tests on MS-Windows leaves zombie processes on the remote 2022-10-25 9:39 ` Henrik Ahlgren @ 2022-10-25 11:26 ` Eli Zaretskii 2022-10-25 13:56 ` Henrik Ahlgren 0 siblings, 1 reply; 18+ messages in thread From: Eli Zaretskii @ 2022-10-25 11:26 UTC (permalink / raw) To: Henrik Ahlgren; +Cc: 43226 > 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#43226: 28.0.50; Running Tramp tests on MS-Windows leaves zombie processes on the remote 2022-10-25 11:26 ` Eli Zaretskii @ 2022-10-25 13:56 ` Henrik Ahlgren 2022-10-25 16:49 ` Michael Albinus 2022-10-25 19:17 ` Eli Zaretskii 0 siblings, 2 replies; 18+ messages in thread From: Henrik Ahlgren @ 2022-10-25 13:56 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 43226 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? ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#43226: 28.0.50; Running Tramp tests on MS-Windows leaves zombie processes on the remote 2022-10-25 13:56 ` Henrik Ahlgren @ 2022-10-25 16:49 ` Michael Albinus 2022-10-25 19:17 ` Eli Zaretskii 1 sibling, 0 replies; 18+ messages in thread From: Michael Albinus @ 2022-10-25 16:49 UTC (permalink / raw) To: Henrik Ahlgren; +Cc: Eli Zaretskii, 43226 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#43226: 28.0.50; Running Tramp tests on MS-Windows leaves zombie processes on the remote 2022-10-25 13:56 ` Henrik Ahlgren 2022-10-25 16:49 ` Michael Albinus @ 2022-10-25 19:17 ` Eli Zaretskii 2022-10-26 11:34 ` Henrik Ahlgren 1 sibling, 1 reply; 18+ messages in thread From: Eli Zaretskii @ 2022-10-25 19:17 UTC (permalink / raw) To: Henrik Ahlgren, Michael Albinus; +Cc: 43226 > 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#43226: 28.0.50; Running Tramp tests on MS-Windows leaves zombie processes on the remote 2022-10-25 19:17 ` Eli Zaretskii @ 2022-10-26 11:34 ` Henrik Ahlgren 2022-10-26 12:01 ` Eli Zaretskii 0 siblings, 1 reply; 18+ messages in thread From: Henrik Ahlgren @ 2022-10-26 11:34 UTC (permalink / raw) To: Eli Zaretskii; +Cc: 43226, Michael Albinus 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#43226: 28.0.50; Running Tramp tests on MS-Windows leaves zombie processes on the remote 2022-10-26 11:34 ` Henrik Ahlgren @ 2022-10-26 12:01 ` Eli Zaretskii 2022-10-26 14:15 ` HA 0 siblings, 1 reply; 18+ messages in thread From: Eli Zaretskii @ 2022-10-26 12:01 UTC (permalink / raw) To: Henrik Ahlgren; +Cc: 43226, michael.albinus > 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). ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#43226: 28.0.50; Running Tramp tests on MS-Windows leaves zombie processes on the remote 2022-10-26 12:01 ` Eli Zaretskii @ 2022-10-26 14:15 ` HA 2022-10-29 14:48 ` Michael Albinus 0 siblings, 1 reply; 18+ messages in thread From: HA @ 2022-10-26 14:15 UTC (permalink / raw) To: Eli Zaretskii; +Cc: michael.albinus, 43226 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, ^ permalink raw reply [flat|nested] 18+ messages in thread
* bug#43226: 28.0.50; Running Tramp tests on MS-Windows leaves zombie processes on the remote 2022-10-26 14:15 ` HA @ 2022-10-29 14:48 ` Michael Albinus 0 siblings, 0 replies; 18+ messages in thread From: Michael Albinus @ 2022-10-29 14:48 UTC (permalink / raw) To: HA; +Cc: Eli Zaretskii, 43226 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. ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2022-10-29 14:48 UTC | newest] Thread overview: 18+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2020-09-05 16:38 bug#43226: 28.0.50; Running Tramp tests on MS-Windows leaves zombie processes on the remote Eli Zaretskii 2020-09-05 19:04 ` bug#43226: Fwd: bug#26911: 25.2; eshell "cd .." doesn't work correctly with TRAMP Michael Albinus 2020-09-05 19:04 ` Michael Albinus 2020-09-05 19:16 ` bug#43226: 28.0.50; Running Tramp tests on MS-Windows leaves zombie processes on the remote Michael Albinus 2020-09-05 19:25 ` Eli Zaretskii 2020-09-06 8:49 ` Michael Albinus 2020-09-06 15:14 ` Eli Zaretskii 2020-09-06 15:54 ` Michael Albinus 2020-09-06 16:07 ` Eli Zaretskii 2022-10-25 9:39 ` Henrik Ahlgren 2022-10-25 11:26 ` Eli Zaretskii 2022-10-25 13:56 ` Henrik Ahlgren 2022-10-25 16:49 ` Michael Albinus 2022-10-25 19:17 ` Eli Zaretskii 2022-10-26 11:34 ` Henrik Ahlgren 2022-10-26 12:01 ` Eli Zaretskii 2022-10-26 14:15 ` HA 2022-10-29 14:48 ` Michael Albinus
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).