tmux exit-empty retains detached sessions preventing server shutdown
0 reputation · 30 Jun 2022, 18:44 UTC
0 reputation · 30 Jun 2022, 18:44 UTC
Configure a tmux server to terminate automatically when no active work remains, minimizing memory footprint for sporadic, low-traffic workloads.
The server option exit-empty (default on) is documented to exit the server when no sessions exist. However, a session created with new-session -d or left detached after client disconnect counts as non-empty, so the server persists indefinitely. The complementary option exit-unattached (default off, tmux 3.3+) exits only when every session has zero attached clients, but a single attached client keeps the entire server alive even if other sessions sit idle. The session option destroy-unattached destroys a session on last detach, yet it discards session state entirely, which may be unacceptable for workloads that need quick resume.
exit-empty be made to treat detached sessions as empty without enabling destroy-unattached?exit-unattached and per-session destroy-unattached provide a clean shutdown path that preserves attached sessions while removing idle detached ones?No. exit-empty cannot be configured to treat detached sessions as empty. The server remains running as long as any session exists, including sessions created with new-session -d or sessions left behind after a client detaches. There is no option that makes exit-empty ignore detached sessions while preserving them.
A combination of exit-unattached and per-session destroy-unattached can stop the server and remove idle detached sessions, but it does not preserve quick-resume state for those detached sessions.
Confirmed: exit-empty ends the server only when zero sessions exist. Detached sessions still count as sessions. Likely explanation: your sporadic workload leaves one or more detached sessions behind, so the tmux server process stays resident even though no client is actively using it.
Use this combination only if you can discard idle session state:
Attached sessions remain while clients are attached. When the last client detaches, exit-unattached can stop the entire server, and any remaining detached sessions are destroyed too.
| Behavior | tmux 3.2 | tmux 3.3+ |
|---|---|---|
| exit-empty | Exits when no sessions exist | Same |
| exit-unattached | Generally unavailable | Available; exits when no attached clients remain |
| destroy-unattached | Confirm per build | Available; destroys session on last detach |
Can you tolerate destroying detached sessions, or must they survive for quick resume? If detached state must survive, neither exit-unattached nor destroy-unattached is suitable; you would need manual kill-session or an external wrapper instead.
Assumption: you are using a standard tmux build, not a patched fork. Option availability depends on the installed version, so verify before production use.
Use comments to ask for clarification. Post a solution as an answer.
34,775 reputation · 01 Jul 2022, 02:17 UTC
To clarify the behavior in tmux 3.3+, exit-unattached operates at the server level, while destroy-unattached operates at the session level. They solve different problems regarding server persistence:
exit-unattached on: The server terminates as soon as the last client detaches, regardless of how many detached sessions still exist. This effectively treats all detached sessions as "empty" for the purpose of server shutdown.destroy-unattached on: The specific session is deleted the moment it becomes unattached.If the goal is to preserve session state for a quick resume but still shut down the server to save memory, exit-unattached is the primary tool. However, note that because the server process terminates, any state not persisted to disk is lost; the sessions are not "hibernated" but are destroyed along with the server process. You can verify this behavior by running tmux -V to ensure version 3.3+ and monitoring the process with pgrep tmux after detaching.