Re: Tramp timeout for currently unreachable connections?

[Michael Albinus]

Visuwesh <visuweshm@gmail.com> writes:

Hi Visuwesh,

>> Idle thought: would enabling 'ServerAliveInterval' help at all here?
>> (my Tramp connections travel from one side of my desk to the other, so
>> I canʼt tell ☺️)

> I have it set to 100 but it doesn't help much.  I don't think I am
> describing my problem well.  I have the following function
>
>     (defun vz/stb--buffer-annotation (buffer)
>       (let ((case-fold-search nil))
>         (pcase (buffer-name buffer)
>           ((rx bos (1+ anychar) "<" (+ (not ">")) ">")
>               (let ((non-essential t))
>                 (vz/with-when (buffer-file-name buffer)
>                   (abbreviate-file-name it)))
>               ;; (let ((non-essential t))
>               ;;   (vz/with-when (vz/file-visiting-buffer-p buffer)
>               ;;     (abbreviate-file-name it)))
>               )
>           ((rx bos "*" (or "shell" "ssh") (? "-"))
>               (let ((non-essential t))
>                 (abbreviate-file-name (buffer-local-value 'default-directory 
> buffer))))
>           (_ (vz/buffer-annotation buffer)))))
>
> that returns an annotation string for my C-x b replacement.  If Tramp
> already knows the connection is dead, non-essential=t signals Tramp to
> not to bother to open a new connection.  I would like a similar variable
> to make Tramp give up after a few seconds if it gets no reply from the
> remote server in the case of connections that are no longer reachable.

I've quoted the Tramp manual in my answer to Robert: "‘ssh’ sessions on
the local host hang when the network is down.  TRAMP cannot safely
detect such hangs."

The reason is, that Tramp just sees a server, which doesn't respond to a
request. It doesn't know the reason for that non-responsiveness. The
request could be, for example, to copy a file of dozens or hundreds MBs
(yes, I've seen this in the wild). This can take a long time, and it
would be intended by the user. There is no good timeout value to stop
waiting the the response.

Best regards, Michael.