Can I start tmux as a child of gnome-session? - gnome

Question

I'm running Ubuntu and use gnome-terminal and would like to run tmux in such a way that it can use all of the gnome-session environment in the same way opening a new terminal window would. E.g. using passphrase-less ssh.
The issue seems to be the process hierarchy...
In a new window of gnome-terminal:
$ pstree -ps $$
init(1)───lightdm(1825)───lightdm(18486)───gnome-session(18552)───gnome-terminal(18626)
Once I enter a new tmux session (even in the above terminal window:
$ pstree -ps $$
init(1)───tmux(15798)───bash(21770)
tmux appears to be a direct child of init and not in the session's process hierarchy. Is there a way to get it to be created as a child of gnome-session?
EDIT: Great answer below (the accepted one)! However I thought I'd include a function I wrote since receiving the answer to update all child bash processes of tmux to the latest environment:
#!/bin/bash
tmup ()
{
echo -n "Updating to latest tmux environment...";
export IFS=",";
for line in $(tmux showenv -t $(tmux display -p "#S") | tr "\n" ",");
do
if [[ $line == -* ]]; then
unset $(echo $line | cut -c2-);
else
export $line;
fi;
done;
unset IFS;
echo "Done"
}

Answer 1

The tmux server calls daemon(3) to detach itself from the process that started it (i.e. the initial tmux client). This is not optional so the server will always be reparented to PID 1 (e.g. init) after the double-fork-and-middle-exit done by daemon(3).
In general, it should not be important that the tmux server is no longer directly “connected” to gnome-session though the parentage of (surviving) processes.
In the case of ssh, the ability to use a key without having to retype its passphrase relies on access to an ssh-agent process. Instances of ssh look for the SSH_AUTH_SOCK environment variable to know where to contact an ssh-agent that can supply keys for it. gnome-session probably arranges to start an ssh-agent and populate its environment with the appropriate SSH_AUTH_SOCK value. This environment is inherited from parent to child as your various processes are started. In this way, the tmux server will also inherit the SSH_AUTH_SOCK value (from the initial tmux client, which got it from a shell, which got it from gnome-terminal, which got it from gnome-session).
A problem occurs, however, when you attach to a tmux session that was started from a different environment. Consider the following scenario that is hinted at by the fact that the PID of your tmux server is lower than that of your gnome-session:
Log in to a GUI session.
gnome-session starts an ssh-agent and configures SSH_AUTH_SOCK=foo in its environment; this value will be inherited by all of its future children.
You start a tmux server (via a shell and gnome-terminal).
The tmux server inherits SSH_AUTH_SOCK=foo; it will be passed on to its children (e.g. a shell running in a tmux session).
You disconnect from your tmux session and log out of your GUI session.
The tmux server and its children still have SSH_AUTH_SOCK=foo, but that value is probably no longer valid (when gnome-session is winding down, it probably killed the ssh-agent that it started).
Later, you log back in to a GUI session.
This time gnome-session sets SSH_AUTH_SOCK=bar and passes it along to its children.
You reconnect to your tmux session.
At this point, you have SSH_AUTH_SOCK=bar “outside” tmux and SSH_AUTH_SOCK=foo “inside” the session. This is the probably where you run into problems.
Effectively, since the tmux server has outlived the original GUI session, any environment variables it initially inherited that were specific to that session are potentially invalid (unless they happen to use exactly the same values the next time you log into a GUI session).
Luckily, tmux has a feature for handling this scenario. The update-environment session option specifies a list of environment variables that are copied into (or removed from) the “session environment” when a client creates or attaches to a session. SSH_AUTH_SOCK is a part of the default value of this option, so it is updated when you reattach. But, tmux is only able to update its “session environment” (which will be inherited by any new children of that session).
Unfortunately, tmux has no way to update any existing processes that are a part of that session (indeed, this is impossible, short of debugging tools that can tinker with the internals of already running processes). So, any existing shells running in windows/panes after the above scenario will probably be using an invalid SSH_AUTH_SOCK. ssh will not complain about the invalid value, it will just prompt you for the appropriate key’s passphrase.
What you might try doing is extracting the value of SSH_AUTH_SOCK from the session environment and incorporating it into the pre-existing shells from your old session with a command like this:
SSH_AUTH_SOCK=$(tmux show-environment | awk '/^SSH_AUTH_SOCK=/ { sub(/.*=/,""); print }')
If you are having issues related to other environment variables, then you may need to add them to update-environment (e.g. set-option -ga update-environment ' FROBNIZ' in your ~/.tmux.conf) and do something similar to copy the values into any existing shells after you reattach from a different context.