Netplan try rollback behavior during SSH session timeouts

Question

Network Configuration Safety Mechanism
Ubuntu uses Netplan as a declarative abstraction layer to manage network settings via backend renderers such as systemd-networkd or NetworkManager. To prevent permanent loss of connectivity during remote configuration changes, the netplan try command implements a timeout-based rollback mechanism.

Configuration Uncertainty
There is a specific interaction between the netplan try timer and active SSH sessions. While the utility is designed to prevent lockouts, the exact behavior when a session is interrupted or when multiple concurrent sessions exist during the confirmation window is not fully defined in the standard documentation.

Does the rollback timer reset or persist if an SSH session drops before the user provides confirmation?
  How does the utility determine the primary session for confirmation in a multi-user environment?

Tasadduq Burney · Answer

Short answer
An SSH session timeout does not reset or cancel the netplan try rollback. The countdown runs on the host. If you do not confirm before it expires, the temporary network configuration is reverted. The SSH connection is only the channel you use to confirm; it is not the rollback trigger.

What is confirmed vs. version-dependent
Confirmed: netplan try is designed as a safety net. It applies a candidate configuration, waits for an explicit confirmation, and reverts if confirmation does not arrive. The rollback is local to the machine, so a dropped SSH client does not keep the new configuration alive.
Version-dependent: the exact default timeout and the precise moment rollback starts after stdin closes may differ between netplan releases. Do not rely on a remembered number such as 30 or 120 seconds. Check the installed documentation and help output before using it on a remote host.
man netplan
netplan try --help

Multi-session behavior
netplan try is not a shared approval prompt. The session that runs the command owns the temporary state and the confirmation step. Other SSH sessions do not automatically become the confirmer. If the original session drops, the timer still expires and the configuration reverts. Avoid running overlapping netplan try commands from different sessions; that can make the active temporary state and rollback target harder to reason about.

Likely explanation

The rollback is driven by a local process or timer, not by SSH keepalives.
When the SSH session times out, the confirmation prompt may receive EOF or simply stop being answered.
Either path leads to the same safety outcome: no confirmation means revert.

Practical steps for this case

Before changing a remote host, arrange console or out-of-band access.
Run sudo netplan try and confirm promptly if the new configuration works.
If you need a longer window, use the supported timeout option after checking help, for example sudo netplan try --timeout 120 only if your version accepts it.
If the session drops, wait for the rollback, then reconnect and verify the old state.
Check the renderer and logs: ip addr, networkctl status, or nmcli device status; then journalctl -u systemd-networkd or journalctl -u NetworkManager.

Do not disable systemd timers or network services blindly to prevent rollback. That can turn a safe revert into a lockout.

One diagnostic detail that changes the recommendation
Are you trying to understand why the rollback happened, or are you trying to keep a configuration despite an SSH timeout? If you need to keep it, the recommendation changes: use a maintenance window with console access, a longer verified timeout, or netplan apply only when you can recover locally.

Netplan try rollback behavior during SSH session timeouts

Network Configuration Safety Mechanism

Configuration Uncertainty

1 answer

0 question comments

Short answer

What is confirmed vs. version-dependent

Multi-session behavior

Likely explanation

Practical steps for this case

One diagnostic detail that changes the recommendation

Your perspective belongs here.