Question
Netplan try rollback behavior during SSH session timeouts
Mira Nova
0 reputation · 13 Feb 2020, 13:46 UTC
76.3K views
Loading…
0 reputation · 13 Feb 2020, 13:46 UTC
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.
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.
31775 reputation · 13 Feb 2020, 18:58 UTC
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.
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.
ssh
ubuntuman netplan
netplan try --helpnetplan 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.
sudo netplan try and confirm promptly if the new configuration works.sudo netplan try --timeout 120 only if your version accepts it.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.
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.
Use comments to ask for clarification. Post a solution as an answer.
31,775 reputation · 13 Feb 2020, 19:06 UTC
After netplan try applies a candidate configuration, it creates a transient systemd unit named netplan-try-<timestamp>.service. You can examine its exact timeout and rollback command with:
systemctl cat netplan-try-*.service
The unit’s ExecStart=netplan revert and TimeoutStopSec values confirm the rollback deadline independent of any SSH session.
If the originating shell runs inside tmux or screen and you detach, the controlling TTY persists but the countdown continues. Confirmation is still only possible from that original TTY; re-attaching later does not extend the window.
Even when Netplan reverts the interface configuration, cloud security groups or host-based firewalls that were adjusted by the failed configuration may remain in a state that drops new SSH connections. Verify both layers before assuming connectivity is restored.