bug#70901: 30.0.50; Tramp doesn't use ControlMaster even with (setq tramp-use-connection-share nil)

[Dmitry Gutov]

Hi Michael,

On 15/05/2024 11:17, Michael Albinus wrote:

> > Shouldn't it then take advantage of ControlMaster, which has been
> > configured for this host?
>
> It should. You could check which settings will be used by calling
> 'ssh -G fencepost.gnu.org'.

$ ssh -G fencepost.gnu.org | grep -i control
controlmaster auto
controlpath /home/dgutov/.ssh/master-fencepost.gnu.org:22
controlpersist 600

> > ssh logs in to the remote server very quickly from the terminal with
> > my ControlMaster configuration.
> >
> > But I don't see any speed improvement in Tramp operations from it. For
> > example, I evaluate just 'ls' using M-& (async-shell-command), and the
> > time it takes to complete doesn't seem to be affected by the contents
> > of my ~/.ssh/config.
>
> Sure. The connection is fast. But then, Tramp makes an initial
> hand-shake, which needs some roundtrips.

What gives me pause is that is there is a message in the echo area 
saying "Connecting ..." which stays there for a while.

And that the time to do this does not depend on ControlMaster being 
enabled - it's around 4 seconds either way.

Starting an asynchronous process does start a new connection, right? 
Simply logging in with ssh to fencepost without ControlMaster takes the 
same several seconds.

And if we put asynchronous processes aside: suppose I restart Emacs and 
then try to visit a remote file from history. The message

  Opening connection nil for dgutov@fencepost.gnu.org using ssh...

stays around for several seconds. And the length of time it stays around 
doesn't seem affected by my ControlMaster configuration in .ssh/config 
(I change the hostname in the config, restart Emacs, try this, change 
the hostname back, restart Emacs - and the time to connect is the same). 
So it seems like some problem remains there, which would be nice to try 
to resolve.

> Set
>
> (add-to-list 'tramp-connection-properties
>               (list (regexp-quote "/ssh:fencepost.gnu.org:")
>                     "direct-async-process" t))
>
> prior connecting the host the very first time in Tramp. This should
> improve the speed. Since it doesn't ask for passwords interactively, you
> might configure your password via auth-source.

Two observations:

1. First of all, it *is* faster. Thank you, a significant improvement.
2. When I invoke async-shell-command for the first time, it takes about 
a second. And the buffer has "Process *Async Shell Command* finished" at 
the end.

Then, while the *Async Shell Command* buffer exists, I invoke it a 
second time, it works even faster than that (e.g. 300ms), but at the end 
the *Async Shell Command* buffer finished with just the output, no 
"Process *Async Shell Command* finished" text at the end. If I kill the 
buffer, invoking the command takes ~1 second again.

In the first scenario (buffer does not exist), *Messages* contains this:

Tramp: Inserting 
‘/ssh:dgutov@fencepost.gnu.org:/home/d/dgutov/.tramp_history’...done
error: "Cannot resize window #<window 8 on *Messages*>"

In the second (buffer exists), just this:

-l: finished.

I should also note that when async-shell-command is invoked locally, it 
doesn't print the text "Process *Async Shell Command* finished" in 
either case.

> See the discussion in (info "(tramp)Improving performance of asynchronous
> remote processes")

I haven't tried it before partly because 
https://www.gnu.org/software/tramp/#Improving-performance-of-asynchronous-remote-processes 
still says that tramp-remote-path is not supported (I guess this has 
been fixed in the master version). And the tramp-own-remote-path thingy 
is very useful for my work scenario.