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

Previous Next

Full log

View this message in rfc822 format

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Michael Albinus <michael.albinus <at> gmx.de>
Cc: 70901 <at> debbugs.gnu.org
Subject: bug#70901: 30.0.50; Tramp doesn't use ControlMaster even with (setq tramp-use-connection-share nil)
Date: Wed, 15 May 2024 17:45:02 +0300

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 <at> 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 <at> 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.

Previous Next

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