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: Michael Albinus <michael.albinus <at> gmx.de>
To: Dmitry Gutov <dmitry <at> gutov.dev>
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 20:15:00 +0200

Dmitry Gutov <dmitry <at> gutov.dev> writes:

> Hi Michael,

Hi Dmitry,

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

This looks proper.

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

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

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

Again, it isn't only the ControlMaster option. And it depends also,
whether there is already an existing connection, which can be reused.

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

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?

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

Best rtegards, Michael.

Previous Next

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