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
- 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.
- 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,tty,cmd listing), often shown as tmux: server; exact presentation is
tmux-version- and platform-dependent, so treat this as a strong hint, not a guarantee. Cross-
check by connecting once (tmux ls) and then finding who holds the socket:
lsof /tmp/tmux-$(id -u)/default or fuser -v /tmp/tmux-$(id -u)/default.
- Check when the socket directory was recreated, to date the event:
stat /tmp/tmux-$(id -u) — a Birth timestamp much later than the server's start time means
the directory was deleted and silently recreated. Birth isn't always available (tmpfs and
some filesystems omit it and print -); when it's missing, fall back to stat -c '%Y'
(mtime) or the server's own start time (ps -o lstart= -p <server-pid>) for the same
comparison.
- Confirm live windows/panes under the orphaned server before deciding anything:
pstree -p <server-pid> and ps --ppid <server-pid>. All panes under a surviving server
process keep running regardless of whether their client is currently attached or detached —
survival depends on the server process, not on client attachment. An already-attached
client's terminal also stays usable, since its connection was established before the socket
vanished; a detached session is not at any extra risk and should be checked with the same
care as an attached one.
- Rule out the routine suspects before blaming an ad hoc script: check whether
systemd-tmpfiles-clean.timer actually ages /tmp with systemd-tmpfiles --cat-config
(merges /usr/lib/tmpfiles.d, /etc/tmpfiles.d, and /run/tmpfiles.d in override order —
checking only the vendor file under /usr/lib/tmpfiles.d/tmp.conf can miss an /etc
override) — a bare - age field in the effective config means aging is disabled — and
whether a known cleanup cron's schedule lines up with the timestamp from step 3.
Recovery is a trade-off, not a fix
There is no way to make a running tmux server re-bind a socket that was deleted while it was
alive — stock tmux has no "recreate my socket" or "adopt an orphaned server" command. The
choice is:
- Leave it running. Already-attached panes keep working exactly as before. You lose the
ability to
tmux ls, attach a new client, or open new windows on that server — but nothing
currently running is interrupted. Right default whenever any pane holds work you can't easily
reproduce (an active agent session, a long build, an SSH tunnel).
- Kill and restart. Only way to regain
tmux ls/attach/new-window. Kills every window on
that server, including ones you didn't check. Never do this without first walking through the
diagnosis steps above and confirming with whoever depends on those panes.
Default to leaving it running and reporting what's alive, unless the user has already confirmed
losing those panes is fine.
Prevention
Any cleanup routine that touches /tmp broadly — cron job, agent-run script, disk-space
recovery — must exclude /tmp/tmux-* (and other live-process sockets: /tmp/ssh-*,
/tmp/.X11-unix, /tmp/.ICE-unix, etc.). A directory holding a live process's control socket
is not stale just because its files look old; staleness has to be judged by whether the owning
process still exists, not by file age alone.
1---2name: tmux-orphaned-socket3description: Diagnose and recover from "error connecting to /tmp/tmux-*/default (No such file or directory)" when tmux ls or attach fails but sessions were working before. Use when a tmux socket has gone missing, especially after any /tmp cleanup, disk-space sweep, or agent-run cleanup script — never assume the sessions are lost before checking.4---56# Tmux Orphaned Socket78`tmux ls` failing with `error connecting to /tmp/tmux-<uid>/default (No such file or directory)`9does not mean the sessions are gone. A running tmux server keeps its windows alive in memory10even after its own socket file is deleted out from under it — deleting a Unix domain socket11file doesn't touch the process holding it open, it only blocks *new* connections. This is the12usual outcome of a `/tmp` cleanup (a cron sweep, an agent-run script, a manual `rm -rf /tmp/*`)13that didn't exclude `/tmp/tmux-*`.1415## Diagnose, don't assume16171. Confirm the socket is actually missing, not just misnamed:18 `ls -la /tmp/tmux-$(id -u)/` — expect it empty, not absent: tmux itself recreates19 `/tmp/tmux-<uid>` (mode 0700) on its own next invocation, including the `tmux ls`/`attach`20 that surfaced the error, so by the time you're reading this the directory almost always21 exists again — an "absent" directory is essentially unreachable once any tmux command has22 run as that uid. `pam_systemd` creates `/run/user/<uid>`, not this directory, and23 `systemd-tmpfiles` manages `/tmp` broadly rather than per-uid tmux dirs specifically, so24 don't attribute the recreation to either of them.252. Check whether the server process is still alive, and identify the server specifically —26 `ps aux | grep '[t]mux'` lists clients and the server indistinguishably:27 `ps -eo pid,ppid,cmd | grep '[t]mux'` and look for the process with no controlling terminal28 (`?` in a `ps -eo pid,tty,cmd` listing), often shown as `tmux: server`; exact presentation is29 tmux-version- and platform-dependent, so treat this as a strong hint, not a guarantee. Cross-30 check by connecting once (`tmux ls`) and then finding who holds the socket:31 `lsof /tmp/tmux-$(id -u)/default` or `fuser -v /tmp/tmux-$(id -u)/default`.323. Check when the socket directory was recreated, to date the event:33 `stat /tmp/tmux-$(id -u)` — a `Birth` timestamp much later than the server's start time means34 the directory was deleted and silently recreated. `Birth` isn't always available (tmpfs and35 some filesystems omit it and print `-`); when it's missing, fall back to `stat -c '%Y'`36 (mtime) or the server's own start time (`ps -o lstart= -p <server-pid>`) for the same37 comparison.384. Confirm live windows/panes under the orphaned server before deciding anything:39 `pstree -p <server-pid>` and `ps --ppid <server-pid>`. All panes under a surviving server40 process keep running regardless of whether their client is currently attached or detached —41 survival depends on the server process, not on client attachment. An already-attached42 client's terminal also stays usable, since its connection was established before the socket43 vanished; a detached session is not at any extra risk and should be checked with the same44 care as an attached one.455. Rule out the routine suspects before blaming an ad hoc script: check whether46 `systemd-tmpfiles-clean.timer` actually ages `/tmp` with `systemd-tmpfiles --cat-config`47 (merges `/usr/lib/tmpfiles.d`, `/etc/tmpfiles.d`, and `/run/tmpfiles.d` in override order —48 checking only the vendor file under `/usr/lib/tmpfiles.d/tmp.conf` can miss an `/etc`49 override) — a bare `-` age field in the effective config means aging is disabled — and50 whether a known cleanup cron's schedule lines up with the timestamp from step 3.5152## Recovery is a trade-off, not a fix5354There is no way to make a running tmux server re-bind a socket that was deleted while it was55alive — stock tmux has no "recreate my socket" or "adopt an orphaned server" command. The56choice is:5758- **Leave it running.** Already-attached panes keep working exactly as before. You lose the59 ability to `tmux ls`, attach a new client, or open new windows on that server — but nothing60 currently running is interrupted. Right default whenever any pane holds work you can't easily61 reproduce (an active agent session, a long build, an SSH tunnel).62- **Kill and restart.** Only way to regain `tmux ls`/attach/new-window. Kills every window on63 that server, including ones you didn't check. Never do this without first walking through the64 diagnosis steps above and confirming with whoever depends on those panes.6566Default to leaving it running and reporting what's alive, unless the user has already confirmed67losing those panes is fine.6869## Prevention7071Any cleanup routine that touches `/tmp` broadly — cron job, agent-run script, disk-space72recovery — must exclude `/tmp/tmux-*` (and other live-process sockets: `/tmp/ssh-*`,73`/tmp/.X11-unix`, `/tmp/.ICE-unix`, etc.). A directory holding a live process's control socket74is not stale just because its files look old; staleness has to be judged by whether the owning75process still exists, not by file age alone.