tmux-orphaned-socketlisted

# Tmux Orphaned Socket `tmux ls` failing with `error connecting to /tmp/tmux-<uid>/default (No such file or directory)` does not mean the sessions are gone. A running tmux server keeps its windows alive in memory even after its own socket file is deleted out from under it — deleting a Unix domain socket file doesn't touch the process holding it open, it only blocks *new* connections. This is the usual outcome of a `/tmp` cleanup (a cron sweep, an agent-run script, a manual `rm -rf /tmp/*`) that didn't exclude `/tmp/tmux-*`. ## Diagnose, don't assume 1. Confirm the socket is actually missing, not just misnamed: `ls -la /tmp/tmux-$(id -u)/` — expect it empty, not absent: tmux itself recreates `/tmp/tmux-<uid>` (mode 0700) on its own next invocation, including the `tmux ls`/`attach` that surfaced the error, so by the time you're reading this the directory almost always exists again — an "absent" directory is essentially unreachable once any tmux command has run as that uid. `pam_systemd` creates `/run/user/<uid>`, not this directory, and `systemd-tmpfiles` manages `/tmp` broadly rather than per-uid tmux dirs specifically, so don't attribute the recreation to either of them. 2. Check whether the server process is still alive, and identify the server specifically — `ps aux | grep '[t]mux'` lists clients and the server indistinguishably: `ps -eo pid,ppid,cmd | grep '[t]mux'` and look for the process with no controlling terminal (`?` in a `ps -eo pid