[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Tramp timeout for currently unreachable connections?
From: |
Visuwesh |
Subject: |
Re: Tramp timeout for currently unreachable connections? |
Date: |
Thu, 12 Sep 2024 23:15:18 +0530 |
User-agent: |
Gnus/5.13 (Gnus v5.13) |
[வியாழன் செப்டம்பர் 12, 2024] Michael Albinus wrote:
> 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.
Thanks, so the only realistic option is to adjust those ssh variables to
a sensible value then. I was under the impression that there existed a
variable or function that would force Tramp to use a specific timeout
value but in retrospect, I see that it would be unreliable. Thank you
once again for pointing to the manual making me realise my initial
misunderstanding of the ssh variables.
> Best regards, Michael.
Thank you for your patience in answering my questions!