I'm using secureCRT to ssh to Linux based server.
I use "screen" command to keep my sessions alive.
But things are becoming strange when I using two PC, OK, here's the scene:
On PC-A, start a new screen session named "test";
On PC-B, type screen -D -r test
Hopefully, I'd like to see the 'test' session detached on PC-A, and re-attached to PC-B.
That works, but when PC-A got remotely detached by PC-B, PC-A lost its connection to server.
Just reconnect will be okay, sure, but I'm still want to know why PC-A lost its connection.
Here's the command log of PC-A
[#PC-A ~]$ screen
[remote power detached]
Screen session of test
ended.
Press Ctrl+C to cancel or Enter to reconnect immediately.
Reconnecting in 1 seconds...
Last login: Fri Mar 8 21:16:50 2013 from 10.129.215.167
[#PC-A ~]$ _
And here is my .screenrc file:
#se the startup message
startup_message off
term xterm
##set a biger buffer
defscrollback 4096
#statusbar
hardstatus alwayslastline
shell zsh
shelltitle "$|zsh"
hardstatus alwayslastline "%{=b}%{Y}%-w%{.BW}%10>%n*%t%{-}%+w%< %=%{kG}(F5)New (F6)Kill (F7)Rename (F8)Next %C%A %D, %Y-%m-%d "
vbell off
## w to show the window list
bind w windowlist -b
bind ^w windowlist -b
##initial apps to run
screen
select 0
attrcolor u "-u B"
sessionname test
autodetach off
#shot-key bindings
bindkey -k k5 screen
bindkey -k k6 kill
bindkey -k k7 title
bindkey -k k8 next
screen by default launches with multiuser set to off. That means when a user logs in, it kicks the previous one out. Change that to your .screenrc and you should be fine.
http://linux.die.net/man/1/screen (search for multiuser).
Related
I have a running process that I've started with screen.
I want to enable log file "on the fly" sending CTRL+a SHIFT+H from a script:
screen -dr process -X stuff ^A H , screen says --> -X: stuff: invalid option
screen -dr miner -X stuff "^A H" , screen says nothing but log file is not enabled
Using -p 0 does not make any difference.
Basically what I need is to send SHIFT+H as it seems that for screen it's not the same to send "H" than SHIFT+H
Don't send the key strokes; just send the command log which is what ^A H (by default) is bound to.
screen -dr process -X log
I created a screen "myscreen" in linux and it stopped responding abruptly. I closed the terminal and tried to reopen it. "screen -ls" shows that the screen is Attached. I tried the following commands but nothing responds.
screen -r myscreen
screen -D myscreen
screen -D -RR myscreen
screen -X -S myscreen quit
Any help to reattach to the screen or to kill the screen is very much appreciated.
screen -X -S SCREENID kill
alternatively, you can use the following command
screen -S SCREENNAME -p 0 -X quit
You can view the list of the screen sessions by executing screen -ls
Create screen from Terminal:
screen -S <screen_name>
To see list of screens:
<screen -ls> or <screen -list>
To go to particular screen:
<screen -x screen_name>
<screen -r screen_name>
Inside screen
To Terminate screen:
give ctrl+d screen will get terminated
To Detach screen:
give <ctrl+ad>or <screen -d >screen will get detached
To reattach screen:
screen -x <screen_name> or screen -r <screen_name>
To kill a screen from Terminal:
<screen -X -S screen_name quit>
or
<screen -X -S screen_name kill>
You can use screen_name or process_id to execute commands.
This worked for me very well. Get the screen id via:
screen -r
or
screen -ls
then kill the screen: kill -9 <screenID>
it now becomes a dead screen,
then wipe it out with: screen -wipe
To kill a detached screen use this from the terminal:
screen -X -S "SCEEN_NAME" quit
If you are attached, then use (from the terminal and inside the screen):
exit
From Screen User's Manual ;
screen -d -r "screenName"
Reattach a session and if necessary detach it first
You could create a function to kill all existing sessions. take a look at Kill all detached screen sessions
to list all active sessions use
screen -r
when listed, select with your mouse the session you are interested in and paste it. like this
screen -r
Suppose your screen id has a pattern. Then you can use the following code to kill all the attached screen at once.
result=$(screen -ls | grep 'pattern_of_screen_id' -o)
for i in $result;
do
`screen -X -S $i quit`;
done
i usually don't name my screen instances, so this might not be useful, but did you try screen -r without the 'myscreen' part? usually for me, screen -r will show the PIDs of each screen then i can reattach with screen -d -r <PID>
You can find the process id of the attached running screen.
I found it same as the session id which you can get by command:
screen -ls
And you can use following command to kill that process:
kill [sessionId] or sudo kill [sessionId]
None of the screen commands were killing or reattaching the screen for me. Any screen command would just hang. I found another approach.
Each running screen has a file associated with it in:
/var/run/screen/S-{user_name}
The files in that folder will match the names of the screens when running the screen -list. If you delete the file, it kills the associated running screen (detached or attached).
For result find: Click Here
Screen is a full-screen window manager that multiplexes a physical terminal between several processes, typically interactive shells. There is a scrollback history buffer for each virtual terminal and a copy-and-paste mechanism that allows the user to move text regions between windows.
Can I run tmux locally and connect via ssh to remote machine.. and after that any new pane and/or screen to be with the remote-machine-shell...
What I'm saying I can't install tmux on the remote machine, but I don't want to do a ssh connection from every pane, but ssh-login just once.
Is such thing possible..
thanks
If you want to login just once, you can use ControlMaster feature of ssh. Add some config like this to your ~/.ssh/config:
ControlMaster auto
ControlPath /tmp/ssh_mux_%h_%p_%r
If you login to the same server (as the same user) multiple times (either in one tmux or not), ssh will reuse the connection so that you don't need to make connection and login again.
lilydjwg explained something I never really understood before. Knowing about the ControlMaster setting makes the following much more reasonable, as it simplifies making multiple ssh connections. You only need to authenticate once, and the remote host doesn't need to have an sshd process running for each connection.
In your .tmux.conf file:
# What host do you usually log in to?
# We'll ssh there by default each time a new window or pane is opened.
REMOTE_HOST=your.usual.host
set-option -g default-command "ssh $REMOTE_HOST"
# Simple interface to change which host is connected to when you create
# a new window or pane.
bind-key C-h command-prompt -p "Set remote host: " -I $REMOTE_HOST "set-option default-command 'ssh %%'"
# In case you really do want a new window with a local shell.
bind-key C new-window ""
I don't think tmux can. One workaround would be to add something like this to tmux.conf.
bind-key X new-window "ssh HOST"
Then new windows would start at the remote host.
I am using tmux 1.8 and did not find a built-in solution. These workarounds fit at least for my common use cases:
Capture the full pane content and search for the last ssh command in it (I use the knowledge about the ending of my prompt to detect the command more or less reliably)
If this fails I check the command the pane might have been created with by using the shell-command option of tmux new-window or split-window commands
My reconnect.sh script looks like this. The most dirty thing about it is the way to get the last ssh command from the buffer. Up to now "> ssh " was enough for my situations to reliably detect a line containing a ssh connection request but any better solution would be appreciated.
#!/bin/bash
# #TODO: change this according to your own prompt
# This is used to find lines connect ssh command in the pane buffer
PROMPT_SEPARATOR="> "
# get current pane buffer size and dimensions
HISTORY_LIMIT=`tmux display-message -p "#{history_limit}"`
VISIBLE_LINES=`tmux display-message -p "#{pane_height}"`
# search last ssh command in pane content
LINE=`tmux capture-pane -p -J -S -$HISTORY_LIMIT -E $VISIBLE_LINES | grep "${PROMPT_SEPARATOR}ssh " | tail -1`
if [ -n "$LINE" ]; then
echo $LINE | sed "s/.*$PROMPT_SEPARATOR//;"
else
# fall back to the command that might have been used to create the pane
# (not necessarily ssh but helpful anyway)
tmux list-panes -F "#{pane_active} #{pane_start_command}" | grep "^1 " | tail -1 | cut -d ' ' -f2-
fi
I saved this script in my ~/.tmux directory and changed key bindings for various split-window and new-window shortcuts in my .tmux.conf similar to this:
# try to reconnect to remote host when creating new window
bind c run-shell 'CMD=`~/.tmux/reconnect.sh`; tmux new-window "$CMD"'
Here's what's happening to me: I start tmux sessions using tmux -L name1, tmux -L name2; then I detatch them using ctrl+B+d. Then I try to get a list of the currently running sessions on my computer. However, when I run tmux ls, I get an error message:
failed to connect to server: Connection refused
Is this a bug? I'm familiar with screen; I regard screen -ls as a very useful function since I might start a session and leave it running for weeks before the next time I attach to it. Because of this, the ability to list current running tmux sessions is quite important for me. Why does tmux ls return a "connection refused" error when I know tmux is running?
TL;DR: Try sending SIGUSR1 signal to the tmux server process.
In my case, after about 8 days of inactivity, I was not able to reattach:
$ tmux attach
no sessions
However, a grep for tmux process got me this output:
$ ps -aef | fgrep -i tmux
hari 7139 1 1 2016 ? 2-20:32:31 tmux
hari 25943 25113 0 22:00 pts/0 00:00:00 fgrep --color=auto -i tmux
As suggested by #7heo.tk, this indicates that tmux server is still running, but tmux ls was giving failed to connect to server: Connection refused error. I verified that the tmp directory that belonged to the tmux session existed and lsof -p 7139 (the pid of tmux server) showed that the socket file is open:
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
tmux 7139 hari 5u unix 0x0000000000000000 0t0 1712879255 /tmp/tmux-50440/default
I also tried explicitly specifying the -S /tmp/tmux-50440/default to tmux but it didn't help. However, I read in the tmux man page that sending SIGUSR1 would make tmux recreate the socket file, so I tried that and I was able to immediately find the session and reattach:
$ kill -s USR1 7139
$ tmux ls
0: 12 windows (created Mon Apr 18 21:17:55 2016) [198x62]
This happens to me when I do not have any sessions running. I'm just starting to use tmux and didn't realize that if you restart your computer you lose your sessions which surprised me at first.
For those of you who are thinking the same thing: Restore tmux session after reboot. A summary of the post: Use shell scripts to build your tmux sessions or create a fancy shell history tracker.
This happened to me when the Ubuntu desktop crashed and my gnome-terminal windows exited. I could still see the tmux process was running (ps aux | grep tmux) but for some reason tmux commands would not work to list the existing sessions. Apparently it wasn't finding the existing Unix socket of the still-running tmux process. The fix in this scenario is to locate the existing Unix socket and specify that to tmux using the -S flag; here's how:
You can find the PID of your still-running tmux process with this:
ps -p $(pidof tmux)
Now take your PID (in my case, 6876) and run this to list any open Unix sockets:
sudo lsof -Uap 6876
Hopefully you see output like this:
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
tmux 6876 abe 3u unix 0x0000000000000000 0t0 408477 socket
tmux 6876 abe 4u unix 0x0000000000000000 0t0 408478 socket
tmux 6876 abe 6u unix 0x0000000000000000 0t0 408479 /tmp/tmux-1000/default
Now you can specify that existing Unix socket to your tmux command (using the -S flag), and you should be able to list-sessions and attach properly:
tmux -S /tmp/tmux-1000/default list-sessions
tmux -S /tmp/tmux-1000/default attach -t 0
You get this error indeed if there are no session open. If there are no sessions open there is no tmux server running so it can't connect to it.
With the -L option, you change the socket name the tmux server uses, it's not a way to name your sessions. You better use the following commands:
tmux new -s name1
tmux new -s name2
These will create 2 sessions on a server with the default socket name. Now you can do:
$ tmux ls
name1: 1 windows (created Mon Sep 22 10:34:40 2014) [158x40] (attached)
name2: 1 windows (created Mon Sep 22 10:34:43 2014) [158x40] (attached)
And you see all the sessions running on the server on the default socket. You can reattach one of them using:
tmux attach -d -s name1
-s specifies the name of the session
-d will detach it from it's previous client (if it is attached)
You can also switch between sessions inside tmux with the choose-tree command which by default is assigned to the keystroke C-s (prefix key + s). This is what I usually do.
You may have an error in your .tmux.conf. I had this problem until i took out this line from my .tmux.conf:
set-window-option -g xterm-keys on
You could also try tmux -v and then look at the logs it prints.
One easy fix is to delete the tmp files left by the tmux server, for example, by doing $ rm -rf /tmp/tmux-xxx/.
The way TMUX(1) works is by having a client process (tmux) connect to a server process (tmux too, but not attached to a TTY), as shown in the following ps output:
PID TTY STAT TIME COMMAND
19229 pts/1 S+ 0:00 tmux
19231 ? Ss 0:00 tmux
That shows that the client actually starts before the server (one could assume it forks it).
After detach/re-attach, the same ps command outputs:
PID TTY STAT TIME COMMAND
19231 ? Ss 0:00 tmux
19290 pts/1 S+ 0:00 tmux attach
This shows the tmux client as tmux attach, thus being a bit easier to understand.
Now, if we look at the output of pstree in both of the above cases, we get in both cases (ignoring the pid change for tmux attach):
pstree -p
init(1)─┬─acpid(1824)
├─cron(1859)
⋮
├─sh(14146)───tmux(19229)
└─tmux(19231)───sh(19233)───pstree(19234)
Clearly showing that the commands typed (pstree in this case) in the client process (PID 19229) get executed by the server one (PID 19231), thus allowing them to continue without SIGHUP in the event where the client terminal is lost (over ssh, for example).
Now, to the question OP asked: what happens in the case where tmux returns failed to connect to server: Connection refused is that the server process (pid 19231 in our case) is unreachable, whatever the reason (it can be because the server process died; but also because the user executing the tmux client doesn't have the permissions to access the tmux socket, etc.)
The solution in that case is to grep for the tmux processes (via ps for example), and pray that you didn't get this error because the server died (so you can attach to it by using lsof to get what sockets it listens to). Otherwise, there is no way to attach to the server, as it is as dead as after a reboot.
TL;DR:
This error can be given for multiple reasons, ranging from bug to critical failure (program died). In a nutshell, use the UNIX tools at your disposal to determine what socket does tmux use, if it is still running (there should be at least two processes if you have the tmux client running - that happens after invoking tmux or tmux attach from the shell) and thus if you lost your session or not.
Note: as other answers pointed out, if the reason for this error to be shown is a socket error, you can use the -L flag to tell tmux to use a specific socket.
This may happen if you or any cleaning process delete files in /tmp/*. All your sessions data are lost if you can't recover those files. Killing all tmux instances and restart it is the only choice left, unfortunately.
I was using another program inside of tmux (reattach-to-user-namespace), and I was getting this error when I switched computers because reattach-to-user-namespace was not installed. The fix was to simply run brew install reattach-to-user-namespace.
This happened to me because I ran tmux with another user (was root), and I tried to list sessions with my normal user..
So you might want to check the user with which you ran your tmux first.
To do so:
$ ps -aef | fgrep -i tmux
root 7139 1 1 2016 ? 2-20:32:31 tmux
centos 25943 25113 0 22:00 pts/0 00:00:00 fgrep --color=auto -i tmux
See the username in the first column: here it's root
Try tmux -L name1 list-session.
I am running a script on a remote server. I ran the script in screen, however I need to stop it before it completes since I need to update the script. I can easily detach from screen, however, is there a way to kill a screen process?
CTRL+a and then 'k' will kill a screen session.
There are a couple of 'screen' ways to kill a specific screen session from the command line (non-interactively).
1) send a 'quit' command:
screen -X -S "sessionname" quit
2) send a Ctrl-C to a screen session running a script:
screen -X -S "sessionname" stuff "^C"
In both cases, you would need to use 'screen -ls' to find the session name of the screen session you want to kill ... if there is only one screen session running, you won't need to specify the -S "sessionname" parameter.
I used this to quit hundreds of erroneous screen sessions created by a buggy command:
for s in $(screen -ls|grep -o -P "1\d+.tty"); do screen -X -S $s quit; done;
where: the grep -o -P "1\d+.tty" is the command to get session names with Perl-like name regex "1\d+.tty" which captures all sessions start with number 1, has some other numbers (\d) and end with .tty
Warning:
You should test with this command first to see you get the exact list of sessions you want before apply the above command. This is to avoid quitting unwanted sessions:
for s in $(screen -ls|grep -o -P "1\d+.tty"); do echo $s; done;
I always to this echo test whenever the list in for loop is not clear, for example, the one generated by sub-command in $() expansion.
previous answers didn't work for me on a winputty terminal and amazon ssh server connection.. but this one does work:
screen -S yourscreentitlehere -X stuff $'\003'
references:
Sending ctrl-c to specific screen session
$'\003' is ctrl+c http://donsnotes.com/tech/charsets/ascii.html
stuff is https://www.gnu.org/software/screen/manual/screen.html#Paste
I am using putty, and it seems I am already in the screen and couldn't open and close. Every time I do "exit", I just close the putty window. Here is the termimal print
>>screen -r
21063.unlimited (11/08/20 15:45:19) (Attached)
24054.cure6 (11/08/20 09:46:13) (Attached)
There is no screen to be resumed.
and
screen -S 21063.unlimited -X stuff $'\003'
does not do anything.
I found that as simple as the following line works perfect
screen -x 21063.unlimited
it sends me back into the screen and from there "exit" works.
Note that it is lower-case -x