Open aseltmann opened 4 years ago
Hi, Thanks for reporting this issue! It sure looks complicated. I will try to look into it, but I might not be able to help you..
If I understand correctly, you can use tmux detach
when you manually login to the remote and attach to the tmux session, but this fails when you execute it from an ob-tmux source block?
tmux detach
not working was just an illustration that inside the tmux session, which is created through ob-tmux, the tmux version is different than outside.
So on this remote machine I log in to there are two tmux versions: a global one under /bin/tmux
with version 1.8 and a local one under /usr/local/bin/tmux
with version 3.0a. I need 3.0a.
/usr/local/bin/tmux
with version 3.0a/bin/tmux
with version 1.8In my first comment I added some remarks pointing out what worked as intended and what did not work.
Hi, Thanks for the clarifying comment. I believe I understand the problem now :)
I tried to reproduce the problem for myself by first creating a socket forwarded socket:
export HOST=<remote> ;
ssh $HOST -tfN -L ~/.ssh/.tmux-$HOST:$(ssh $HOST 'tmux ls -F "#{socket_path}"' | head -1)
And by creating a new session from the socket:
tmux -S ~/.ssh/.tmux-$HOST new-session -d -s "session-from-socket" -n "0"
Then by creating a new session on the remote:
ssh $HOST
tmux new-session -d -s "session-from-remote" -n "0"
After attaching, If I compare
env | sort
on the two sessions, I only see minor differences (DISPLAY
is defined in one of the sessions, but not on the other for instance)
I get the same result for
tmux -V
on both sessions. I have versions 2.8 locally and 2.3 remotely.
So it could be that your tmux versions are just incompatible. Have you tried comparing the socket creation with the two different tmuxes? ie:
export HOST=<remote> ;
ssh $HOST -tfN -L ~/.ssh/.tmux-$HOST:$(ssh $HOST '/bin/tmux ls -F "#{socket_path}"' | head -1)
or
export HOST=<remote> ;
ssh $HOST -tfN -L ~/.ssh/.tmux-$HOST:$(ssh $HOST '/usr/local/bin/tmux ls -F "#{socket_path}"' | head -1)
Perhaps this is the culprit?
I finally found some time to try this out:
As you can see there are bigger differences in env | sort
, I think especially PATH
is relevant, but some other fields are different as well. Maybe it is important to stress, that I think the problem arises from 2 different tmux versions at the remote (which is a common thing for multi-user server setups, I think).
So it could be that your tmux versions are just incompatible. Have you tried comparing the socket creation with the two different tmuxes? ie:
ssh $HOST '/bin/tmux ls -F
...: After logging into the first SSH, this fails with the following message (the second SSH is not getting prompted):
protocol version mismatch (client 7, server 8)
Bad local forwarding specification '/home/USER/.ssh/.tmux-HOST:'
ssh $HOST '/usr/local/bin/tmux ls -F
...: Works. Same result (see tables above) as ssh $HOST 'tmux ls -F
.Since the socket creation is only possible with the second version, and the same problem persists, this does not seem to be the culprit.
EDIT: Today when using the output function discussed in issue #6 I experienced something new: I could send the command to the tmux remote server (verified via direct ssh control over command line), BUT after calling org-babel-open-src-block-result
in the org-edit-special
buffer I just got:
#+RESULTS:
: server version is too old for client
After I did (setq org-babel-tmux-location "/usr/local/bin/tmux")
it worked again as before.
To check the output of my tmux session, I have to attach to the session in a terminal (output directly to org is not yet supported). I noticed that I can not "tmux detach" or "tmux ls" because of tmux version issues. Using
C-b d
to detach still works. So I can work around it, but I noticed this inconsistency and wanted to report it. Edit: I found out the reason for this behaviour - it is that the tmux session I attach to itself is created by tmux 3.0a, but the tmux path inside the session is different and so the tmux version is different as well (1.8). Therefore they are not compatible and the active tmux session can not be controlled via shell commands. This only happens with ob-tmux and not with a manually created session - this is what I wanted to report with this issue.On my local machine I've got (works as expected)
On the remote machine I've got (works as expected):
If I open a tmux session from my terminal and start a new session with
tmux new -d
and then attach to it I get (works as expected):If I use ob-tmux to open a tmux session following the README where in the end I have a code block somewhat like this
#+BEGIN_SRC tmux :socket ~/.tmux-local-socket-remote-machine :session tmuxtest
and then attach to it from my terminal I get (does not work as expected):I already tried to specify the desired path
/usr/local/bin/tmux
inorg-babel-tmux-location
(and soft- and hardlinked tmux on my own machine to this place, since otherwise ob-tmux did not create a session. The result was still the one you see above.Here are some details on my setup, please tell me if you need more:
GNU Emacs 26.3 Org mode version 9.1.9 (release_9.1.9-65-g5e4542 @ /usr/share/emacs/26.3/lisp/org/) ```elisp (use-package ob-tmux ;; Install package automatically (optional) :ensure t :custom (org-babel-default-header-args:tmux '((:results . "silent") ; (:session . "default") ; The default tmux session to send code to (:socket . nil))) ; The default tmux socket to communicate with ;; The tmux sessions are prefixed with the following string. ;; You can customize this if you like. (org-babel-tmux-session-prefix "ob-") ;; The terminal that will be used. ;; You can also customize the options passed to the terminal. ;; The default terminal is "gnome-terminal" with options "--". (org-babel-tmux-terminal "xterm") (org-babel-tmux-terminal-opts '("-T" "ob-tmux" "-e")) ;; Finally, if your tmux is not in your $PATH for whatever reason, you ;; may set the path to the tmux binary as follows: (org-babel-tmux-location "/usr/local/bin/tmux")) ```