TRAMP multi-hop connection retry behavior during privilege escalation

Question

TRAMP Connection Retries and Sudo Boundaries
Emacs TRAMP handles transient failures by automatically retrying operations based on the tramp-retry-connection-attempts setting. In multi-hop configurations, such as /ssh:user@host|sudo:root@host:/path, TRAMP maintains a cached connection to the primary host and a subprocess for the escalated user.
A potential conflict arises when a write operation fails due to a transient network error or a timeout. TRAMP may trigger a retry that re-establishes the sudo session. If the remote sudo configuration has a short timestamp_timeout or requires a TTY, this retry can trigger an unexpected password prompt mid-operation without verifying if the previous write attempt partially succeeded.
Currently, tramp-retry-connection-attempts applies globally to both read and write operations, providing no mechanism to suppress retries specifically for non-idempotent write actions across permission boundaries.

Is there a configuration to disable automatic retries specifically for write operations while maintaining them for reads?
How can TRAMP be configured to prevent redundant sudo authentication prompts during a retry sequence?

Tasadduq Burney · Answer

TRAMP Retry Behavior and Sudo Boundaries
There is currently no built-in TRAMP configuration to selectively disable automatic retries for write operations while keeping them enabled for read operations. TRAMP's connection management treats the multi-hop vector as a single pipeline; if a failure triggers a reconnection attempt, it re-establishes the entire chain, including the escalated sudo session.

Likely Cause of Redundant Prompts
When a transient error occurs during a write, TRAMP may attempt to re-initialize the connection. If the remote sudo configuration has a timestamp_timeout set to 0 (or a very low value), the new subprocess spawned by TRAMP cannot leverage a previous authentication ticket. This forces a fresh password prompt mid-operation, regardless of whether the previous write partially succeeded.

Recommended Resolutions
To prevent redundant authentication prompts during retry sequences, you must address the session persistence on the remote host rather than the retry logic within Emacs.

Increase Sudo Timestamp Timeout: Modify the remote /etc/sudoers file (via visudo) to allow a grace period for re-authentication. 
    Defaults timestamp_timeout=15
    This ensures that if TRAMP restarts the sudo process within 15 minutes, no password is required.
  Optimize Connection Caching: Ensure TRAMP is not prematurely tearing down connections. While not a per-operation toggle, increasing tramp-connection-timeout can reduce the frequency of full reconnection cycles during transient lag.
  Verify Operation State: Because TRAMP cannot distinguish between idempotent reads and non-idempotent writes during a retry, you should manually verify the remote file state (size or checksum) if a write fails before manually triggering a save again.

Verification and Diagnostics
To confirm if a retry is triggering a fresh sudo authentication, use the following steps:

Set (setq tramp-verbose 6) in your Emacs configuration.
  Perform the write operation that triggers the failure.
  Inspect the *tramp-debug* buffer to see if TRAMP is executing a new sudo command and if the remote shell is returning a password prompt string.

Missing Diagnostic Detail: Please provide the specific Emacs version and the exact variable name used for tramp-retry-connection-attempts, as this is not a standard documented variable in current stable TRAMP releases and may be part of a specific distribution or custom patch.

TRAMP multi-hop connection retry behavior during privilege escalation

TRAMP Connection Retries and Sudo Boundaries

1 answer

TRAMP Retry Behavior and Sudo Boundaries

Likely Cause of Redundant Prompts

Recommended Resolutions

Verification and Diagnostics

Your perspective belongs here.

0 question comments