This has already been reported as a Debian bug, <http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=529082>. If another user creates a path /tmp/tmux-$UID, user $UID cannot start tmux.
An easy fix would use XDG_RUNTIME_DIR by default, but that depends on fixing bug 753882.
Denied by PM for 7.1, moving to 7.2 planning list. :/
Denied by PM for 7.2, moving to the 7.3 planning list.
Tired of dragging this one forward and never getting it approved. Approving for 7.3. Will implement what Debian did for this problem so there is at least some consistency across vendors (plus, Debian's fix has been present in their packages since 2009).
(In reply to Florian Weimer from comment #0)
> An easy fix would use XDG_RUNTIME_DIR by default
And that is not the fix we're trying to apply. Instead, there are attempts to move socket file to /run and make tmux sgid to be able to write there.
I do not believe upstream tests or supports running tmux as sgid. I see that both Debian and Fedora used to have sgid tmux at some point, but abandoned the idea.
Debian has this in NEWS.Debian:
tmux (1.4-7) unstable; urgency=low
Starting with version 1.4-7, tmux is no longer installed setgid utmp and
server sockets are no longer placed under /var/run/tmux, reverting to
the default upstream behavior (sockets in a user directory under /tmp).
We recommend that you close any open tmux sessions before proceeding
with the upgrade. If necessary, old servers can be accessed after the
upgrade with e.g. "tmux -S /var/run/tmux/tmux-`id -u`/default attach".
-- Romain Francoise <firstname.lastname@example.org> Sat, 16 Apr 2011 19:16:23 +0200
SUSE also rejected setgid approach, afaics:
Do we have a reason to believe that the approach that turned out to be wrong for both Fedora and Debian is the right thing to do for RHEL?
Florian, any thoughts from you as the reporter of this issue?
Following upstream and other major distributions and not installing tmux as setgid.