Re: Default connection timeout for the sudo method
Michael Albinus <[email protected]> Sat, 16 Aug 2025 16:14:16 +0200
| Newsgroups | gmane.emacs.tramp |
|---|---|
| Message-ID | <[email protected]> |
"R. Diez" <[email protected]> writes: > Hi again: Hi, >>> The trouble is, the manual does not say what the predefined value for s= uch connections are. >> The default value is 300 seconds. You're right, the manual shall >> mention it. I've checked the Tramp manual. It speaks about the 5 minutes session timeout in (info "(tramp) Inline methods") , item =E2=80=98sudo=E2=80=99. > Something is not quite right. To the best of my knowledge (I am no Emacs = guru), I haven't configured tramp-connection-properties anywhere. However, = its value is reported as: > > Its value is (("/sshfs:" "direct-async-process" t)) > Original value was nil This is a deprecated setting in Tramp 2.7. Pls ignore; it doesn't harm. > If I do customize-variable, tramp-connection-properties, then it states "= CHANGED outside Customize". Yes, due to the setting in Tramp. > In any case, 300 seconds are 5 minutes, but it only takes a few seconds t= o timeout. These are the corresponding log entries in *Messages*: > > Tramp: Timeout session /sudo:root@my-hostname: > Cleaning up the recentf list... > File /sudo:root@my-hostname:/etc/prometheus/prometheus.yml removed from t= he recentf list > Cleaning up the recentf list...done (1 removed) > > [...] > > Tramp: Timeout session /sudo:root@my-hostname: > Cleaning up the recentf list... > File /sudo:root@my-hostname:/etc/prometheus/prometheus.yml removed from t= he recentf list > Cleaning up the recentf list...done (1 removed) > > More such messages keep appearing, even though I haven't modified the rem= ote file (any further) for a while. > > Furthermore, most timeout messages do not appear in any of the Tramp debu= g logs. This is the only one I have seen with some delay: Without a *complete* Tramp debug buffer I cannot say anything. And I won't. > Note also the wrong new-line character after "=E2=80=98killed". This comes from the process sentinel, nothing relevant for Tramp. Ignore it. > The lack of timely connection timeout messages in the debug log makes deb= ugging harder, because the *Messages* buffer has no timestamps, so it is ha= rd to see what is causing trouble when. If you want to see timestamps, the Tramp debug buffer is the way to go. If it doesn't work proper for you, we must investigate. > Best regards, > rdiez Best regards, Michael.