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
Related
I'm currently working on a script which interact with another process.
If it is relevant, the said process is a simdebug console. What I want is exiting it properly because when I kill the process itself, it creates a lock file .lck.
The Simdebug console is waiting for inputs and closes on receiving quit, then q and n, both sperated by an enter keypress to validate the command.
I managed to send some commands to the Simdebug using
echo quit > /proc/< PID >/fd/1
But it only print the results of the echo and I can't find how to send a enter keypress, only new lines '\n' .
I can't aswell manage to send a quit command which would execute directly in the Simdebug and not the terminal where it is sent from.
My question would be resolved if one of those two points is answered:
Is it possible to simulate a validate keypress as in :
Term 1 : echo ifconfig ; echo < enter keypress>
Which would then execute what's in the read buffer of the Term 2
Is there a way to already execute a commande in another process as in
Term 1 : < unknown syntax > pwd
Term 2 < shows pwd of term2 not term1>
Which would not be working only from terminal to terminal but with an already opened process in read mode.
This is actually a hard thing to do. If you send characters to the /proc/self/fd/0 device or similar stdin device link from a different master terminal then it will just output the characters to the output side of the master terminal of the other process.
With tools like expect or pdip or screen you can send anything you want to a process encapsulated in their pseudoterminals as if it comes from their master terminal. But if a process is running then it will already have it's own terminal.
You can be in luck if your console can be persuaded for a controlling terminal transfer with reptyr.
For example if your console has process id 999999 (and you have screen and reptyr installed and maybe did something to appease selinux or apparmor/yama protections):
screen -dmS automateconsole
screen -S automateconsole -p 0 -X stuff 'reptyr 999999^M'
screen -S automateconsole -p 0 -X stuff 'quit^M'
sleep 1s
screen -S automateconsole -p 0 -X stuff 'q^M'
sleep 1s
screen -S automateconsole -p 0 -X stuff 'n^M'
sleep 1s
screen -S automateconsole -p 0 -X stuff 'exit^M'
But note:
You probably should cleanup the program that init'ed the console.
On Ubuntu at least I could not reptyr processes from other SSH sessions.
https://github.com/nelhage/reptyr
http://theterminallife.com/sending-commands-into-a-screen-session/
I want to write a bash script to re-attach to the existing linux screen, perform some commands and then detach from that screen. I know to create a new linux screen in detached mode and perform some commands. But I haven't found a way to re-attach to a existing linux screen.
You can give a name to a screen session by using the -S option.
Example : screen -dS NAME <command>
Then you can reattach to that session using screen -r NAME
try this;
user#host:/screen -ls
There are screens on:
29229558.pts-5.host (Detached)
46661728.pts-22.host (Detached)
user#host:/screen -r 46661728.pts-22.host
If you see (attached) as below;
user#host:/screen -ls
There are screens on:
29229558.pts-5.host (Detached)
46661728.pts-22.host (Atached)
screen -D -r 46661728.pts-22.host
To re-attach to the screen you have to follow this steps:
Before de-attaching from the screen, execute:
STDOUTTERM=$(who -m|awk '{print $2}')
Then you can attach stdout to whatever you want. When you finish, to reattach to stdout, execute this:
exec > /dev/$STDOUTTERM
You can send a command to a running screen using screen -X exec. See the man page for redirection options.
screen -X exec ls
Alternatively you can send text to a running screen's stdin buffer using screen -X paste, as if the user had typed it. This can be a way of running commands inside an interactive shell.
screen -X register a "ls\n"
screen -X paste a
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).
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.
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