This has been puzzling me for a while. I use tmux on a remote server via ssh. Tmux makes sure I don't have to worry about accidentally losing connection to the server. However, I found out every time I lost the connection, my terminal keeps reporting mouse interactions.
Losing connection to remote tmux session, will firstly give me this message client_loop: send disconnect: Broken pipe. After this, all mouse interaction within this
shell session will show following gibberish. It requires me to open another shell session to get rid of this behavior. This happens both to my macOS Terminal and another terminal emulator I'm using, kitty. Therefore I believe this is due to some bad configuration in my shell or tmux.
0;58;42M0;58;42m65;50;44M66;50;44M65;50;44M65;50;44M65;50;44M66;50;44M65;50;44M65;50;44M65;50;44M67;50;44M65;50;44M65;50;44M65;50;44M65;50;44M65;50;44M65;50;44M65;50;44M65;50;44M65;50;44M65;50;44M65;50;44M65;50;44M65;50;44M65;50;44M65;50;44M65;50;44M67;50;44M65;50;44M65;50;44M67;50;44M65;50;44M65;50;44M65;50;44M65;50;44M65;50;44M65;50;44M65;50;44M65;50;44M65;50;44M65;50;44M65;50;44M65;50;44M65;50;44M65;50;44M65;50;44M65;50;44M65;50;44M65;50;44M65;50;44M65;50;44M65;50;44M67;50;44M65;50;44M65;50;44M65;50;44M67;50;44M65;50;44M65;50;44M67;50;44M65;50;44M65;50;44M65;50;44M67;50;44M65;50;44M65;50;44M65;50;44M67;50;44M65;50;44M65;50;44M67;50;44M65;50;44M65;50;44M65;50;44M67;50;44M65;50;44M65;50;44M65;50;44M67;50;44M65;50;44M65;50;44M65;50;44M67;50;44M65;50;44M65;50;44M67;50;44M65;50;44M64;50;44M64;50;44M64;50;44M64;50;44M64;50;44M66;50;44M64;50;44M64;50;44M64;50;44M64;50;44M65;51;50M65;51;50M65;51;50M65;51;50M67;51;50M65;51;50M65;51;50M65;51;50M65;51;50M65;51;50M65;51;50M65;51;50M65;51;50M65;51;50M0;1;44M32;2;44M32;3;44M32;4;44M32;5;44M32;6;44M32;7;44M32;8;44M32;9;44M32;10;44M32;11;44M0;11;44m0;20;48M0;20;48m0;20;47M0;20;47m0;53;50M0;53;50m0;63;47M0;63;47m
My tmux version is 1.8. And the tmux.conf file has the following mouse related lines
# Use mouse
setw -g mode-mouse on
set -g mouse-select-window on
set -g mouse-select-pane on
set -g mouse-resize-pane on
set -g mouse-utf on
I'm wondering if anyone knows how to resolve this.
Many thanks in advance!
Related
(OS: Windows; using PowerShell)
Background
I intend to have "git pull" run from time to time by my service (i.e. Windows Service). In order to achieve it I use TortoiseGitPLink to provide git with my SSH key every time it's needed. This is done by setting the env var:
$env:GIT_SSH_COMMAND="'C:/Program Files/TortoiseGit/bin/TortoisePlink.exe' -i c:/path/to/my/key/id_rsa.ppk -pw myKeyPassword"
This works fine in general, but if I make a mistake and specify wrong path to my SSH key or wrong password, then TortoisePLink hangs indefinitely, freezing therefore my service. Also, If I stop the service, there's still TortoisePLink process hanging around.
Reading Plink's doc I found a "-batch" switch:
-batch: disable all interactive prompts
but for some reason either it is not respected or I use it in a wrong way.
Question
Is there a way to use TortoiseGitPLink to reliably provide an SSH key? By "reliably" I mean: it should fail if any pop-up appears or the key file is missing.
I am trying to do some work on a remote machine and disconnect without terminating the work. I have tried both nohup and screen, unfortunately it is not working out. After I type exit to logout my work also terminates immediately.
I am trying to run 108 simulations on a remote machine. For that purpose I have written a script named batch.sh which runs one simulation after the other until all 108 are done. The program that actually runs a simulation launches 5 programs in 5 different terminals (using xterm -e). I run batch.sh using:
nohup bash batch.sh &
As long as I am connected everything works just fine. If I disconnect and then reconnect to check whether everything is working as it should...no joy :(
Are there any caveats I am overlooking? Possibly because my program launches other programs in external terminals?
UPDATE
If I use the suggestions of adding -oForwardX11=no to ssh and unset DISPLAY before launching my script I get these errors:
nohup: ignoring input and appending output to nohup.out
In nohup.out I have these messages:
xterm Xt error: Can't open display:
xterm: DISPLAY is not set
Apparently your script/program is trying to launch xterm on its own. These days many systems enable X11 forwarding for their SSH client by default - as a result the DISPLAY variable is set in your shell session but becomes invalid once you disconnect. Therefore, as long as you are connected to the remote system, the xterm processes can access the X server on your local machine through the SSH connection, but die once that connection is severed.
I have occasionally encountered the same issue with Java programs that use e.g. the Java AWT subsystem to generate image files, even when there is no actual graphical window. You should first see if your program will somehow adapt if there is no X server available. One option is to disable X11 forwarding with the -oForwardX11=no option to ssh:
$ ssh -oForwardX11=no user#server.host.name
You could also try unsetting the DISPLAY environment variable before starting your script and see what happens.
However, if your program is launching xterm windows indiscriminately then you'd have to make it e.g. use an output file on the server instead - by modifying it, if necessary. As an added advantage, you would get rid off the network load and timing overhead involved with forwarded X connections.
If you cannot change the way your program works and you do not actually care about the output in those xterm windows, then you could try launching a virtual framebuffer X server on the remote system and have your script use that for xterm.
I connected via ssh to remoute server and started very long wget downloading. Then ssh session was broke, and after reconnect new copy of interpretator was created. Now I see wget process in ps, but is it possible to return control to old interpretator? I know that better solution is to use screen for long commands, but is there other way?
No, there is no way to reattach a process to a different terminal if it's not set up to do that (by way of screen / tmux / what have you) in the first place.
As a crude approximation, connecting a debugger to the running process may allow you to interact with it in some limited ways, but in this particular scenario, I don't think it will be beneficial.
If you want to know the progress of your currently running wget, check out the size of the downloaded file, it should be growing. If it doesn't, run killall wget and start over.
Next time, consider running wget --background to prevent the problem from happening. See the wget info page.
This command let Wget to work in the background, and write its progress to log file my.log.
Еhe number of retries 45 (-t options)
wget -t 45 -o my.log http://upload.wikimedia.org/wikipedia/commons/5/51/Google.png &
While writing code inside a tmux session, I inadvertently pressed a sequence of keys that has made my status bar disappear.
I haven't touched my tmux config file, and I verified the status bar is visible in new tmux sessions. Disconnecting and reconnecting to this session didn't help.
Read through the man page and searched through Google, no luck so far.
Running the following commands from inside the session didn't help:
^B :set-option -g status-bg default
^B :set-option -g status on
I have many windows open and would prefer not to have to destroy this session. Any help would be appreciated.
From the tmux command line, issue:
:set status on
to turn the status bar on. You can simplify this by adding a line to your .tmux.conf:
# toggle statusbar
bind-key b set-option status
and then reload your config.
Not quite a solution, but a possible workaround.
I'll assume your old session is number 0; adjust the argument to -t as necessary.
tmux new-session -t 0
This creates a new session which has all the same windows as session 0. If you create a new window in one session, it appears in the other as well. If you delete a window from one, it is removed from the other. More importantly, the new session should have a status bar. Then, you can try removing the old status-free session:
tmux kill-session -t 0
This should not affect the windows in session 0, since they are all part of your new session as well.
I know these kinds of questions have been asked for years, and the answer to them are often Screen or tmux.
I surely will use screen at beginning if I know I will leave the session for a long time, or the network is too bad to maintain a reliable connection.
The main problem is when I start some session and find it must last long later, or the connection just lost accidentally. In the later case, often when I start another session immediately, I can find the previous processes are not killed at that time, but I just have no way to reconnect to their terminal.
So I wonder if it is possible to prevent normal processes from killed even long time after accidentally disconnected SSH session. And the most important is I can reconnect to their terminals with out start them in Screen in advance.
If not, is is possible to move a already started bare ssh session into a new Screen session for later reconnect?
I don't believe it's possible without something like screen. Once your pseudo-TTY is lost I'm almost certain it can't be recovered from a different shell (at least not without some narly hacks).
As far as adding an existing process to a new screen I think that is possible. Try the instructions here:
http://monkeypatch.me/blog/move-a-running-process-to-a-new-screen-shell.html
The first thing to do is to suspend the process. In my case, Irssi can be suspended by typing Ctrl + Z.
Secondly, resume the process in background:
$ bg
Now, we will detach the process from its parent (the shell). So, when the parent process will be terminated, the child (Irssi) will be able to continue. For this, we use the disown builtin:
$ disown irssi
Launch a screen session:
$ screen
As we are in a screen session, we will retrieve the irssi process. To do so, we use the reptyr command which take a pid:
$ reptyr
To avoid the tedious pid research, we can use the pgrep command:
$ reptyr $(pgrep irssi)
Now the process is in a screen shell, we can safely detach our session and no longer worry about killing our X server or close our ssh connection.
You'll need reptyr for this.
OPTION 2:
I suspect you may be trying to solve the wrong problem. If your SSH connection is dropping, why not address that? You can set SSH to be incredibly tolerant of timeouts and disconnects by tweaking your connection settings.
On your client, in $HOME/.ssh/config add:
ServerAliveInterval 60
ServerAliveCountMax 5
Now your sessions won't timeout even if the server doesn't respond for 5 minutes.
Use ssh-tmux instead of tmux:
function ssh-tmux(){
if ! command -v autossh &> /dev/null; then echo "Install autossh"; fi
autossh -M 0 $* -t 'byobu || {echo "Install byobu-tmux on server..."} && bash'
}
I worked on a text file using nano and I got disconnected. After I logged in I saw the nano process from the previous session was still running, but I couldn't switch to that nano instance. So, I killed the nano process and then it created file named filename.save. Which had my changes from the first session.