Listing Sessions
GNU Screen & Linux Job Control
Chapter 3 · Listing & Identifying Sessions
Once you use screen regularly, you'll have several sessions running — some you remember, some you don't. This chapter shows how to list them, read their IDs, tell which state each one is in, and clean up the ones you no longer need.
Listing Sessions
Typical output looks like this:
screen -ls doesn't start a session; it just prints one line per session, with its ID, often its
start time, and its state. The exact date format and the socket directory vary between systems and versions.
Reading a Session ID
| Part | Example | Meaning |
|---|---|---|
| PID | 24817 | The process ID of that session's screen server process |
| Name | backup | The name you gave with -S |
| tty.host | pts-0.myserver | Used as the name when you didn't give one: the terminal it was started from and the machine's hostname |
So a session started with plain screen gets an ID like 23904.pts-0.myserver, while one
started with screen -S backup gets 24817.backup. The PID really is a process: you can
see it with ps.
ps as SCREEN in capitals; the lower-case
screen process is a client attached to it. That's a quick way to tell them apart when you look
through a process list (Chapter 6 goes further).
Referring to a Session
Anywhere screen wants a session — -r, -x, -d, -S with
-X — you can use the full ID, the PID alone, the name alone, or the start of the name, as long
as only one session matches.
backup. If you then use the name alone, screen
lists the matches and asks you to be more specific. Using the PID, or the full PID.name, always
identifies exactly one session.
Session States
| State | Meaning | What to do |
|---|---|---|
| Detached | Running, with nobody connected | screen -r to reattach |
| Attached | Running, and connected to a terminal — possibly one that's no longer really there | screen -d -r or screen -x (Chapter 2) |
| Multi | Shared in multi-user mode (Chapter 9) | Attach as allowed by its access settings |
| Dead ??? | The server process is gone (for example after a crash or reboot) but its socket file is left behind | screen -wipe to remove it |
Where Sessions Live: Sockets
Each session has a socket — a special file clients use to talk to the server — in
a per-user directory, shown on the last line of screen -ls. On many modern systems that's
/run/screen/S-yourname; older systems use /var/run/screen or /tmp/screens,
and the SCREENDIR environment variable can change it. The socket's file name is the session ID.
Ending Sessions You Don't Need
-X sends one of screen's own commands to a running session without attaching to it; Chapter 9
uses it much more. If a session is truly stuck, kill on the server PID also works, but it's a
last resort — it gives the programs inside no chance to shut down in an orderly way.
Hands-On Exercises
Start one unnamed session and two named ones (web and db), detaching from each. Run screen -ls and, for every line, identify the PID, the name, and the state.
Start two sessions both named test. Try screen -r test, then work out two different ways to reattach to one specific session.
Without attaching, end the web session from Exercise 1. Then deliberately kill -9 the server PID of db, and use screen -ls and screen -wipe to see and clean up what's left.
Chapter 3 Quick Reference
screen -ls(-list) lists sessions without starting one- Session IDs are
PID.name, orPID.tty.hostfor unnamed sessions; the PID is the screen server process, shown asSCREENinps - Refer to a session by full ID, PID, or unambiguous name; use the PID if names clash
- States: Detached, Attached, Multi, and Dead (a leftover socket)
- Sockets live in a per-user directory such as
/run/screen/S-user; sessions don't survive a reboot - End a session with
Ctrl-a \orscreen -S name -X quit; tidy dead ones withscreen -wipe