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 21:15, Michael Albinus wrote:

> > > > 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.
>
> Well, the message is there not only waiting for the network connection,
> but also waiting for Tramp doing its initialization. So you cannot
> compare the time with a simple "ssh ..." from the shell.

But it looks very similar to the time "ssh ..." takes in the shell.

Except when I set up ControlMaster for the host, "ssh ..." in the shell 
starts taking much less time (not having to establish a new connection, 
I take it).

Whereas the time it takes for Tramp to finish "Connecting ..." seems 
unchanged.

> > And that the time to do this does not depend on ControlMaster being
> > enabled - it's around 4 seconds either way.
>
> Yes, because the majority of the time is spent in roundtrips during
> initialization.

Does that mean that, somehow, Tramp is faster at establishing the new 
connection than the terminal ssh?

Then it would make sense that the rest of the time is taken by 
additional work.

> > 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.
>
> Again, it isn't only the ControlMaster option. And it depends also,
> whether there is already an existing connection, which can be reused.

I test and compare by restarting Emacs at the beginning of each 
scenario, or killing the existing connection anyway.

We're supposed to reuse the external connection established by 
ControlMaster, right? I mean, at least at the lower level of the 
implementation.

> > 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.
>
> The "Process ... finished" message comes from a sentinel, IIRC. Tramp
> tries to handle it properly, but there might be a bug. Do you mind to
> open a new bug report?

Okay, I'll do that soon-ish.

> > > 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.
>
> The web page refers to Tramp's stable version, which is 2.6.3 ATM (the
> version in Emacs 29.3). If you build Emacs yourself, you're better to
> consult the Info pages. The rerstriction you mention has been removed in
> tramp.texi a while ago, and etc/NEWS says
>
> --8<---------------cut here---------------start------------->8---
> *** Direct asynchronous processes use 'tramp-remote-path'.
> When a direct asynchronous process is invoked, it uses 'tramp-remote-path'
> for setting the remote PATH environment variable.
> --8<---------------cut here---------------end--------------->8---

That makes sense, thank you.