Screen Command Examples: Get Control of Linux / Unix Terminal

Screen command offers the ability to detach a long running process (or program, or shell-script) from a session and then attach it back at a later time.

When the session is detached, the process that was originally started from the screen is still running and managed by the screen. You can then re-attach the session at a later time, and your terminals are still there, the way you left them.

In this article, let us review the how to manage the virtual terminal sessions using screen command with examples.

Screen Command Example 3: Attach the Screen when required

You can attach the screen at anytime by specifying the screen id as shown below. You can get the screen id from the “screen -ls” command output.

$ screen -r 4491.pts-2.FC547

Screen Command Usage Scenario 1

When you have access to only one terminal, you can use screen command to multiplex the single terminal into multiple, and execute several commands. You might also find it very useful to combine the usage of screen command along with the usage of SSH ControlMaster.

Screen Command Usage Scenario 2

When you are working in a team environment, you might walk over to your colleagues desk and get few things clarified. At that time, if needed, you can even start some process from their machine using screen command and detach it when you are done. Later when you get back to your desk, you can login and attach the screen back to your terminal.

A really huge advantage with using screen (or VNC as I more commonly do), is that when doing work that must not be interrupted, such as an installation or complex update, and your connection may be erratic, you can work from a screen session on a more reliable server, such as inside a corporate data center. That way, if your PC loses its connection, your work is not lost, and you do not face the tedious process of a backout/restart – instead, you just re-connect to your still-running screen session. That approach has saved me a lot of grief over the years in supporting important business applications.

Hi,
There is another important usage of screen command, which is sharing a session between multiple users.
Here is the step to achieve that:

* The screen executable has to setuid
chmod u+s /usr/bin/screen
* Launch a screen session
screen
Type ctrl + a and : ( You will get a prompt at the bottom of the screen to type screen commands)
Type “multiuser on” ( We enabled multiuser session ).
Press ctrl + a and : again.
Type aclchg user5 -w “#” ( username is the name of the user to whom we have to share with. -w is to disable write permission to the user )

Now login as user5 and type
screen -x lakshmanan/

Now the user5 will be able to see what the user lakshmanan is doing in the screen.

So, is this isolated to a per user instance? If I log in as bob, then log into the same machine as sam, does sam get bob’s screen activity when doing screen -ls?

Also if I sudo to root, does root own the screen instance. If bob sudos to root, then sam logs in and sudos to root, could sam see the items that bob started after sudo’ing, or is it on a per sudo basis?

In general I recommend against starting screen like “screen ./unix-command”. When the unix-command exits, the controlling screen will also exit. This will prevent you from seeing any errors, warnings, or output messages. Instead, run “screen” by itself which will cause it to spawn a subshell prompt, then run “unix-command” in the subshell. I do this as my default behaviour so I don’t have to think about whether I need the screen to persist or not.

My logic is that since most things you want to run in screen are long-running tasks that you don’t want interrupted, it’s usually true that you want to see what messages it left on the terminal, especially if it crashed or was killed.

The downside of this approach is that you can’t start screen sessions programmatically (say, at boot). That hasn’t been a problem for me, but as a work around I suppose you could write a shell script that runs your command then blocks on input (“read X”), then run that script as the article originally describes.

Thank you for a great blog. I have a question.
How can we see exactly the command (name, arguments, etc) which is being handled by screen instead of screen ID? If so, I don’t have to attempt to attach into all ID to find expected handled command.

About The Geek Stuff

My name is Ramesh Natarajan. I will be posting instruction guides, how-to, troubleshooting tips and tricks on Linux, database, hardware, security and web. My focus is to write articles that will either teach you or help you resolve a problem. Read more about Ramesh Natarajan and the blog.

Contact Us

Email Me :
Use this Contact Form to get in touch me with your comments, questions or suggestions about this site. You can also simply drop me a line to say hello!.