feat(tmux): add opt-in user-scope tmux launch#467
Open
johnrichardrinehart wants to merge 1 commit intoasheshgoplani:mainfrom
Open
feat(tmux): add opt-in user-scope tmux launch#467johnrichardrinehart wants to merge 1 commit intoasheshgoplani:mainfrom
johnrichardrinehart wants to merge 1 commit intoasheshgoplani:mainfrom
Conversation
Add a tmux config knob so session startup can launch the tmux server outside the caller's session-*.scope. When [tmux] launch_in_user_scope = true is set, agent-deck starts tmux through systemd-run --user --scope instead of invoking tmux directly. This is intended for setups where agent-deck is started from SSH, a display-manager login, or another short-lived login scope. In those cases the tmux server can end up cgrouped under the login session that created it, so tearing down that session kills tmux and agent-deck later treats the session as missing and restarts it. Launching tmux under the user manager keeps the server out of the transient session scope while keeping the behavior opt-in for users who do not want the extra systemd dependency. This only affects tmux servers created after the setting is enabled. Agent-deck still talks to tmux through the default socket, so an already-running default tmux server is not migrated by a later launch with this knob turned on. In mixed local/SSH usage, whichever context creates the tmux server first determines where that server lives until it is restarted.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
TL;DR: If
agent-deckis spawned using an SSH session, then there's a good chance that if the SSH connection is torn down thatagent-deck'stmuxsession will be destroyed. This PR develops an (untested) opt-in configuration knob that allows users to spawnagent-deckin the user scope instead of a session scope (assumingsystemd) in order that theiragent-deckenvironment may hopefully survive things like SSH disconnects.Description
Add a tmux config knob so session startup can launch the tmux server outside the caller's session-*.scope. When [tmux] launch_in_user_scope = true is set, agent-deck starts tmux through systemd-run --user --scope instead of invoking tmux directly.
This is intended for setups where agent-deck is started from SSH, a display-manager login, or another short-lived login scope. In those cases the tmux server can end up cgrouped under the login session that created it, so tearing down that session kills tmux and agent-deck later treats the session as missing and restarts it.
Launching tmux under the user manager keeps the server out of the transient session scope while keeping the behavior opt-in for users who do not want the extra systemd dependency.
Caveat
This only affects tmux servers created after the setting is enabled. Agent-deck still talks to tmux through the default socket, so an already-running default tmux server is not migrated by a later launch with this knob turned on. In mixed local/SSH usage, whichever context creates the tmux server first determines where that server lives until it is restarted.