GNU bug report logs - #62093
30.0.50; tramp: commit 8c6a463 breaks remotely staging chunks in magit

Previous Next

Full log

View this message in rfc822 format

From: Aleksander Trofimowicz <trof <at> n90.eu>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: Benjamin Orthen <benjamin <at> orthen.net>, 62093 <at> debbugs.gnu.org
Subject: bug#62093: [PATCH] Let processes read nothing from stdin in tramp
Date: Mon, 06 Nov 2023 16:51:24 +0000

Hi Michael,

Michael Albinus <michael.albinus <at> gmx.de> writes:

> I wanted to let you know that I found time to check this. Thanks for the
> patch.
>
Thank you for looking into this issue.

> The failed test runs have in common that there is a complex Tramp target
> for the test using multi-hops, like above. I suspect a problem with
> timing due to the several hops, but I don't know exactly what's up.
>
Triggered by your multi-hop tests (host B via host A) I run git-apply
actions over Tramp with the patch I submitted. I settled with 3
different test environment configurations; all of them should provide
the same functionality:

1. An explicit multi-hop target "/ssh:host_A|/ssh:host_B:..."

2. The SSH client option ProxyCommand set to "ssh host_A nc host_B 22" and
simple "/ssh:host_B"

3. The SSH client option ProxyJump set to "host_A" and simple "/ssh:host_B"

tramp-use-connection-share was set to nil in each case.

It worked as expected only in the first two cases. As far as the last one
is concerned, the workflow wasn't stalled, but it turned out to be no-op
after all.

It seems the last test environment enables the most responsive data
stream: no additional userland process is forked on a middle box and
Nagle's algorithm is disabled for all TCP connections involved (which is
not true for the case no 2.). In the end such results might corroborate
your theory.

--
at

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.