From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Aleksander Trofimowicz via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#62093: [PATCH] Let processes read nothing from stdin in tramp Date: Mon, 04 Dec 2023 11:05:56 +0000 Message-ID: <878r6ab4r3.fsf@mx.n90.eu> References: <87wmvaudbi.fsf@n90.eu> <87edh5s9e9.fsf@gmx.de> <877cmupx1c.fsf@n90.eu> <87y1f430al.fsf@gmx.de> <87wmugdpsl.fsf@n90.eu> <874jh4zo47.fsf@gmx.de> Reply-To: Aleksander Trofimowicz Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2948"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Benjamin Orthen , 62093@debbugs.gnu.org To: Michael Albinus Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Dec 04 12:14:19 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1rA6u2-0000XS-V0 for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 04 Dec 2023 12:14:19 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rA6tf-0000C7-Up; Mon, 04 Dec 2023 06:13:55 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rA6tc-0000Bd-Kb for bug-gnu-emacs@gnu.org; Mon, 04 Dec 2023 06:13:53 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rA6tc-0003ht-9z for bug-gnu-emacs@gnu.org; Mon, 04 Dec 2023 06:13:52 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rA6tm-00086n-8Y for bug-gnu-emacs@gnu.org; Mon, 04 Dec 2023 06:14:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Aleksander Trofimowicz Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 04 Dec 2023 11:14:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 62093 X-GNU-PR-Package: emacs Original-Received: via spool by 62093-submit@debbugs.gnu.org id=B62093.170168839531101 (code B ref 62093); Mon, 04 Dec 2023 11:14:02 +0000 Original-Received: (at 62093) by debbugs.gnu.org; 4 Dec 2023 11:13:15 +0000 Original-Received: from localhost ([127.0.0.1]:33568 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rA6t1-00085Z-Ag for submit@debbugs.gnu.org; Mon, 04 Dec 2023 06:13:15 -0500 Original-Received: from mx.n90.eu ([65.21.251.117]:34278) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rA6sv-00085L-ES for 62093@debbugs.gnu.org; Mon, 04 Dec 2023 06:13:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=n90.eu; s=default; t=1701688377; bh=IgjVGvOxxklf+mI7mwurc03TD+5Pb2tLLTyu/jwu1vg=; h=References:From:To:Cc:Subject:Date:In-reply-to; b=UTIXKCtLpZ9b21Xn5O2EOQu/lX2PphJh3suPQZedF2sKjVSvbplVrHyJKCYyHb+Kn OnwmUgRf9zt1Ft4PTsK9iW6KP/kxHNJTCf+LI8py1jH1aOE0IS7Mlv4Vw4oPBd0CVP Nmkbi5iAx22kI0O7X6DdASqhIfyaGd7ELm25sH4YYafKuzXBhs0IAA1Ps0N9scp8en oErMMtcWnsOGv/NmCj2P1sK+yaKpeijQ9Y0KprnqoyhyXwgD8Yrg9W3tPPm7EMX5Vg L3Ax9iU1YUAiQ8WTsRYt1nyeilCJ8GlFrEnao6bg6wRbDEvnRunNaoqSBCyg7Qyy+3 Lym4bn22qEYDQ== In-reply-to: <874jh4zo47.fsf@gmx.de> X-Mailer: boring 1.0 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:275492 Archived-At: Hi Michael, Michael Albinus writes: > I've tried several approaches, none of them did satisfy me > completely. So I have introduced a new user option > tramp-pipe-stty-settings, which you can use for different stty > settings. See appended patch. Let-binding this to "-icanon min 0 time 1" > in magit-start-process has at least solved the problem as shown here in > this bug report. I'm not very happy with this, but it is the best I > could do now. Could you please check? > The patch works as expected. However given the default value of tramp-pipe-stty-settings you opted for, as well as the contents of additional commentary in the code provided by this patch, I have got an irresistible feeling I failed to convey the consequences of maintaining the status quo. So let me show two simple cases: 1) open a terminal window on your local host 1.1. confirm it works in the canonical mode $ stty -a|grep icanon 1.2. write 4 "E" characters to a random file, type ^D once, then write 4 more "E"s, and finally type ^D twice: $ cat > /tmp/testfile EEEEEEEE 1.3. check the contents of the target file with a hex dump utility. Assuming you don't use fancy locale settings, this should look like the following: $ xxd /tmp/testfile 00000000: 4545 4545 4545 4545 EEEEEEEE 2) now the same workflow but in the non-canonical mode 2.1. disable the canonical mode: $ stty -icanon; stty -a|grep icanon 2. write 4 "E" characters to a random file, type ^D once, then write 4 more "E"s, and finally type ^D twice, and observe that the special characters are echoed back and a cat process refuses to terminate. Type ^C to actually terminate the process: $ cat > /tmp/testfile2 EEEE^DEEEE^D^D^C 2.3 check the contents of the file $ xxd /tmp/testfile2 00000000: 4545 4545 0445 4545 4504 04 EEEE.EEEE.. As you can see there are three additional bytes (carrying 0x04 values), each one represents the VEOF character which in the canonical mode is intercepted by the kernel TTY subsystem, and alters the way kernel interacts with a user process. In the non-canonical mode it is simply passed to userspace. Indeed very few programs are prepared to handle those terminal special characters, and if you use one that doesn't then at best it hangs. In less favourable circumstances the process might silently corrupt data along the way or produce other unpleasant results. In the Magit case it is not Magit/Emacs itself that hangs, but a git process upon a read syscall on pts/0 on a remote host: $ ps axjf # filtered for brevity PPID PID PGID SID TTY TPGID STAT UID TIME COMMAND 1 977 977 977 ? -1 Ss 0 0:00 sshd: /usr/bin/sshd -D [listener] 0 of 10-100 startups 977 251082 251082 251082 ? -1 Ss 0 0:00 \_ sshd: guest [priv] 251082 251087 251082 251082 ? -1 S 1000 0:00 | \_ sshd: guest@pts/0 251087 251089 251089 251089 pts/0 251089 Ss+ 1000 0:00 | \_ git --no-pager --literal-pathspecs -c core.preloadindex=true -c log.showSignature=false -c color.ui=false -c color.diff=false apply --cached -p0 --ignore-space-change - $ cat /proc/251089/status|head -n7 Name: git Umask: 0022 State: S (sleeping) Tgid: 251089 Ngid: 0 Pid: 251089 PPid: 251087 [...] # cat /proc/251089/stack [<0>] wait_woken+0x54/0x60 [<0>] n_tty_read+0x588/0x640 [<0>] tty_read+0x134/0x250 [<0>] vfs_read+0x1fe/0x350 [<0>] ksys_read+0x6f/0xf0 [<0>] do_syscall_64+0x5d/0x90 [<0>] entry_SYSCALL_64_after_hwframe+0x6e/0xd8 The git program in the apply mode expects to receive 0 upon read() in order conclude its processing. If tramp-pipe-stty-settings is set to '-icanon min 1 time 0', that is never going to happen, since Magit resorts to use process-send-eof to designate the end of input data, which in turn sends VEOF if it is detected that pty is in use (and it is, since this is what Tramp does behind the scene). The VEOF character looses its special meaning in the non-canonical mode hence a deadlock ensues. Given above I would argue the canonical mode should be set as the default one. > > We have already ssh multiplexing. If you like to avoid pty's at all, you > might try to use direct async processes: > > (info "(tramp)Improving performance of asynchronous remote processes") > In my case that's the optimal solution. Thank you! -- Kind regards, at