Difference between revisions of "Screen notes"

From Noah.org
Jump to navigationJump to search
(14 intermediate revisions by the same user not shown)
Line 1: Line 1:
 
[[Category:Engineering]]
 
[[Category:Engineering]]
== Minimal GNU Screen ==
+
== GNU Screen ==
  
`Screen` allows you to start shells and disconnect and reconnect them from any location. You can start a shell at work; disconnect; go home and reconnect to the same shell. A single screen session can group multiple shells. A user can have multiple screen sessions.
+
`Screen` allows you to start shells or programs in a virtual terminal which you may then disconnect and reconnect from a different location. For example, you can start a shell at work; disconnect; go home; and reconnect to the same shell. A single screen session can group multiple shells and you can have multiple screen sessions.
  
== command-line screen arguments ==
+
'''Documentation warning:''' the documentation for GNU Screen is inconsistent; the documentation uses '''C-x''' notation to indicate a '''CTRL-X''' key combination, but all the screen config files and run-time messages use '''^x''' notation to indicate a '''CTRL-X'''.
  
* `screen` -- start new screen session with one virtual screen.
+
== command-line options ==
** C-a d -- disconnect the session. The session continues in the background as a daemon. You can reconnect later.
 
* `screen -r` -- reconnect to a disconnected session.
 
* `screen -rd` -- force a disconnect of a connected session and then reconnect.
 
  
== control commands inside of screen session ==
+
Although `screen` is a GNU project, it does not follow the GNU convention for CLI options where you use -- in front of a long option. So '-ls' does not indicate multiple options; although, for other options it might. It's best not to worry about it and just remember the few basic options that you commonly need.
 +
 
 +
* screen -- with no options this starts new screen session with a shell in a virtual screen. From inside the session you type '''C-a C-d''' to disconnect the session.
 +
* screen -r -- reconnect to a disconnected session.
 +
* screen -rd -- disconnect a session the is connected somewhere else and then reconnect. Use this if you change terminals and left a session connected elsewhere.
 +
* screen -ls -- list all sessions (connected and disconnected).
 +
 
 +
== control commands used inside of a screen session ==
 +
 
 +
All screen commands start with C-a. Then most of the commands follow with a key that you may type either with CTRL or without. For example, the disconnect command may be typed as either '''C-a C-d''' or as '''C-a d'''.
  
 
* C-a ? -- Show help
 
* C-a ? -- Show help
* C-a d -- Disconnect
+
* C-a d -- Disconnect the session. The session continues in the background as a daemon which you can reconnect to later.
* C-a c -- Create New virtual screen in the current session
+
* C-a K -- KILL the current screen
 +
* C-a c -- Create a shell in new virtual screen. This screen is added to the current session.
 
* C-a n -- Next screen
 
* C-a n -- Next screen
 
* C-a p -- Previous screen
 
* C-a p -- Previous screen
Line 27: Line 34:
 
This is the ~/.screenrc I use. It isn't complicated, but it does show you clearly which screen you are attached to and I like the status bar that shows how to get help. This is a helpful fail-safe for users that forget "C-a ?"  :-)
 
This is the ~/.screenrc I use. It isn't complicated, but it does show you clearly which screen you are attached to and I like the status bar that shows how to get help. This is a helpful fail-safe for users that forget "C-a ?"  :-)
  
Download [http://www.noah.org/downloadsvn.php?src=file:///home/svn/src/dotfiles/.screenrc .screenrc]
+
Download [http://www.noah.org/engineering/src/dotfiles/.screenrc .screenrc]
<include svncat src="file:///home/svn/src/dotfiles/.screenrc" highlight="sh" />
+
<include src="/home/noahspurrier/noah.org/engineering/src/dotfiles/.screenrc" highlight="sh" />
  
 
== Start a screen session with multiple screens ==
 
== Start a screen session with multiple screens ==
Line 56: Line 63:
 
That will start a session with all five hosts attached to one of the screens.
 
That will start a session with all five hosts attached to one of the screens.
  
== multiuser sessions ==
+
== Multiuser sessions -- shared screens ==
  
 
The `screen` command must be setuid root. This is a security weakness, so learn what setuid root means before you do this. As a rule of thumb, setuid is fine for a desktop developer's box, but a bad idea for a production machine. You may also need to set permissions for /var/run/screen to 755.
 
The `screen` command must be setuid root. This is a security weakness, so learn what setuid root means before you do this. As a rule of thumb, setuid is fine for a desktop developer's box, but a bad idea for a production machine. You may also need to set permissions for /var/run/screen to 755.
Line 87: Line 94:
 
<pre>
 
<pre>
 
screen -x owner/shared
 
screen -x owner/shared
 +
</pre>
 +
 +
== using screen as a serial terminal ==
 +
 +
Screen makes a very good serial port terminal. You can connect a screen window to any serial device in /dev. Most serial devices in linux are named like '''/dev/ttyS0''' and '''/dev/ttyS1''' for a built-in RS-232 port; or for USB-to-RS-232 adapters the names are usually like '''/dev/ttyUSB0''' and '''/dev/ttyUSB1'''.
 +
 +
The communication settings are a comma separated list of control modes as would be passed to `stty`. See the man page for `stty` for more info.
 +
 +
Old, slow-speed serial devices usually play nice with 9600 8N1 (9600 baud, 8-bits per character, no parity, and 1 stop bit):
 +
 +
<pre>
 +
screen /dev/ttyS0 9600,cs8,-parenb,-cstopb,-hupcl
 +
</pre>
 +
 +
The previous settings work with the Coyote Point E450si load balancers. The Coyote Point E450si manual calls for the following settings:
 +
 +
<pre>
 +
*9600 baud
 +
*8 data bits
 +
*no parity
 +
*one stop bit
 +
*VT100 terminal emulation
 +
*ignore hang-ups (if supported); this allows a single terminal session to continue running even if Equalizer restarts.
 +
</pre>
 +
 +
These settings are for the serial console of an embedded computer board (115200 8N1):
 +
 +
<pre>
 +
screen /dev/ttyS0 115200,cs8,-parenb,-cstopb,-hupcl
 +
</pre>
 +
 +
== root can take control of user's screen session ==
 +
 +
This was more of an exercise because the root user could just as easily use `su` to become the user and then take control of a screen session that way. I was curious if it was possible to grab an existing screen session and assign it to some other user.
 +
 +
By default user screen sessions are recorded in /tmp/uscreens or /var/run/screen, but you might have to dig around because the user may have reset the SCREENDIR from the default. There are some other SCREENDIR defaults depending on how `screen` was compiled. Here is an example to find the SCREENDIR (really there would be a lot more matches):
 +
 +
<pre>
 +
# lsof -n | grep screen
 +
screen    7833    parker    4r    FIFO              253,2                32772 /tmp/uscreens/S-parker/7833.pts-2.my_host
 +
</pre>
 +
 +
Set your SCREENDIR environment variable:
 +
 +
<pre>
 +
export SCREENDIR=/tmp/uscreens/S-parker
 +
</pre>
 +
 +
Take ownership of the existing SCREENDIR:
 +
 +
<pre>
 +
chown -R root:root /tmp/uscreens/S-parker
 +
</pre>
 +
 +
<pre>
 +
screen -rd 7833.pts-2.my_host
 
</pre>
 
</pre>
  
Line 109: Line 172:
  
 
The "select 0" and "kill" are needed to get rid of the initial virtual screen that was created when the screen session was started with '-d -m'.
 
The "select 0" and "kill" are needed to get rid of the initial virtual screen that was created when the screen session was started with '-d -m'.
 +
 +
== ERROR: Cannot open your terminal '/dev/pts/1' - please check. ==
 +
 +
This happens after you do something like this:
 +
<pre>
 +
su - root
 +
su - other_user
 +
screen
 +
</pre>
 +
 +
When you `su` to root your pseudo-terminal remains owned by the user you logged in as. When you `su` to root this isn't a problem because root can read and write any file. But when you then `su` to '''other_user''' that user is not able to open the pts.
 +
 +
The following is a hack to fix this. This works because the `script` command will create a new pts for the '''other_user'''. The '/dev/null' just tells `script` to throw away the data captured.
 +
<pre>
 +
su - root
 +
su - other_user
 +
script /dev/null
 +
screen
 +
</pre>

Revision as of 04:37, 26 March 2010

GNU Screen

`Screen` allows you to start shells or programs in a virtual terminal which you may then disconnect and reconnect from a different location. For example, you can start a shell at work; disconnect; go home; and reconnect to the same shell. A single screen session can group multiple shells and you can have multiple screen sessions.

Documentation warning: the documentation for GNU Screen is inconsistent; the documentation uses C-x notation to indicate a CTRL-X key combination, but all the screen config files and run-time messages use ^x notation to indicate a CTRL-X.

command-line options

Although `screen` is a GNU project, it does not follow the GNU convention for CLI options where you use -- in front of a long option. So '-ls' does not indicate multiple options; although, for other options it might. It's best not to worry about it and just remember the few basic options that you commonly need.

  • screen -- with no options this starts new screen session with a shell in a virtual screen. From inside the session you type C-a C-d to disconnect the session.
  • screen -r -- reconnect to a disconnected session.
  • screen -rd -- disconnect a session the is connected somewhere else and then reconnect. Use this if you change terminals and left a session connected elsewhere.
  • screen -ls -- list all sessions (connected and disconnected).

control commands used inside of a screen session

All screen commands start with C-a. Then most of the commands follow with a key that you may type either with CTRL or without. For example, the disconnect command may be typed as either C-a C-d or as C-a d.

  • C-a ? -- Show help
  • C-a d -- Disconnect the session. The session continues in the background as a daemon which you can reconnect to later.
  • C-a K -- KILL the current screen
  • C-a c -- Create a shell in new virtual screen. This screen is added to the current session.
  • C-a n -- Next screen
  • C-a p -- Previous screen
  • C-a esc -- Enter Copy/Scrollback mode (esc again to exit scrollback mode). Scrollback mode is very useful.
    • Use Vi-like keys to move around the scrollback history (the usual h,j,k,l for cursor, C-u for half page UP, C-d for half page DOWN).
    • Press SPACE to start selecting a region. Press SPACE again to Yank the region.
    • Press "C-a ]" to paste the yanked text into the current screen.

.screenrc

This is the ~/.screenrc I use. It isn't complicated, but it does show you clearly which screen you are attached to and I like the status bar that shows how to get help. This is a helpful fail-safe for users that forget "C-a ?" :-)

Download .screenrc <include src="/home/noahspurrier/noah.org/engineering/src/dotfiles/.screenrc" highlight="sh" />

Start a screen session with multiple screens

I don't know why `screen` doesn't allow you to start multiple screens from a single command-line invocation. Say you want to start a screen session with 5 screens already started connected to 5 hosts. This is a common use-case for me. But it is not too hard to trick `screen` into doing this. It's a little ugly, but it's fairly easy and simple.

The `screen` command has an option, "-c file", which overrides the default configuration file in ~/.screenrc. You can put screen commands in this file that will get executed when the session starts. Unfortunately this overrides your config options in ~/.screenrc, but you can copy the commands from your ~/.screenrc to the head of your custom screenrc. For example, the following commands could be saved in a file called "five_hosts_screenrc":

startup_message off
defscrollback 10000
hardstatus alwayslastline
hardstatus string "%{kG}%50>%-w%{ky}%n %t%{-}%+w%{-} %>%=%{ky}Ctrl-A ?%{-} for help"
screen -t Host100 ssh 192.168.1.100
screen -t Host101 ssh 192.168.1.101
screen -t Host102 ssh 192.168.1.102
screen -t Host103 ssh 192.168.1.103
screen -t Host104 ssh 192.168.1.104

You would then invoke this configuration with the following command:

screen -c five_hosts_screenrc

That will start a session with all five hosts attached to one of the screens.

Multiuser sessions -- shared screens

The `screen` command must be setuid root. This is a security weakness, so learn what setuid root means before you do this. As a rule of thumb, setuid is fine for a desktop developer's box, but a bad idea for a production machine. You may also need to set permissions for /var/run/screen to 755.

sudo chmod u+s `which screen`
sudo chmod 755 /var/run/screen
  • `screen -S session_name` -- Start a new session with a given name. This makes it easier to find with `screen -ls` described below.
  • `screen -ls` -- list the available sessions.
    • `screen -ls username/` -- list the sessions of a given user. Note the trailing slash.
  • `screen -x username/sessionname` -- connect to a connected session. Use this to share sessions with other people. This is much like `kibitz`.

The session owner starts screen. The owner should give it a name so it is easy to find.

screen -S shared

Once screen has started the session owner needs to turn on multiuser mode and allow a given friend access.

C-a :multiuser on
C-a :acladd friend_username

The friend will then start screen and tell it to connect to the owner's session.

screen -x owner/shared

using screen as a serial terminal

Screen makes a very good serial port terminal. You can connect a screen window to any serial device in /dev. Most serial devices in linux are named like /dev/ttyS0 and /dev/ttyS1 for a built-in RS-232 port; or for USB-to-RS-232 adapters the names are usually like /dev/ttyUSB0 and /dev/ttyUSB1.

The communication settings are a comma separated list of control modes as would be passed to `stty`. See the man page for `stty` for more info.

Old, slow-speed serial devices usually play nice with 9600 8N1 (9600 baud, 8-bits per character, no parity, and 1 stop bit):

screen /dev/ttyS0 9600,cs8,-parenb,-cstopb,-hupcl

The previous settings work with the Coyote Point E450si load balancers. The Coyote Point E450si manual calls for the following settings:

*9600 baud
*8 data bits
*no parity
*one stop bit
*VT100 terminal emulation
*ignore hang-ups (if supported); this allows a single terminal session to continue running even if Equalizer restarts.

These settings are for the serial console of an embedded computer board (115200 8N1):

screen /dev/ttyS0 115200,cs8,-parenb,-cstopb,-hupcl

root can take control of user's screen session

This was more of an exercise because the root user could just as easily use `su` to become the user and then take control of a screen session that way. I was curious if it was possible to grab an existing screen session and assign it to some other user.

By default user screen sessions are recorded in /tmp/uscreens or /var/run/screen, but you might have to dig around because the user may have reset the SCREENDIR from the default. There are some other SCREENDIR defaults depending on how `screen` was compiled. Here is an example to find the SCREENDIR (really there would be a lot more matches):

# lsof -n | grep screen
screen     7833    parker    4r     FIFO              253,2                 32772 /tmp/uscreens/S-parker/7833.pts-2.my_host

Set your SCREENDIR environment variable:

export SCREENDIR=/tmp/uscreens/S-parker

Take ownership of the existing SCREENDIR:

chown -R root:root /tmp/uscreens/S-parker
screen -rd 7833.pts-2.my_host

scripting screen

Note, that the following example is more easily achieved in this section: #Start_a_screen_session_with_multiple_screens. The example below shows how to cause a screen session to start new screen after the session has already started.

You can start a new screen sessions and then send screen commands to that session to have it open new virtual screens. This example starts a screen session and then creates ssh connections to five machines. Finally, you can reconnect to the session and use these screens. This will only work if you have public key certs setup for these machines.

screen -S foo_name -d -m
screen -S foo_name -X screen ssh 192.168.1.100
screen -S foo_name -X screen ssh 192.168.1.101
screen -S foo_name -X screen ssh 192.168.1.102
screen -S foo_name -X screen ssh 192.168.1.103
screen -S foo_name -X screen ssh 192.168.1.105
# select and kill does not always work.
#screen -S foo_name -X select 0
#screen -S foo_name -X kill
screen -S foo_name -r

The "select 0" and "kill" are needed to get rid of the initial virtual screen that was created when the screen session was started with '-d -m'.

ERROR: Cannot open your terminal '/dev/pts/1' - please check.

This happens after you do something like this:

su - root
su - other_user
screen

When you `su` to root your pseudo-terminal remains owned by the user you logged in as. When you `su` to root this isn't a problem because root can read and write any file. But when you then `su` to other_user that user is not able to open the pts.

The following is a hack to fix this. This works because the `script` command will create a new pts for the other_user. The '/dev/null' just tells `script` to throw away the data captured.

su - root
su - other_user
script /dev/null
screen