tmux Sessions and Windows

Goal

You create tmux sessions and windows, check the detached state, verify that the configuration file is really applied to the server, and then build a script that reproduces a development environment.

Why it matters

What actually runs your commands in tmux is not your terminal but the tmux server process. Your terminal is only a client that receives that screen. When SSH drops, the client disappears, but the server and its children are not affected at all, so when you reconnect and attach, you get the screen back exactly as it was. That is the decisive difference from nohup: nohup keeps the work alive but does not give you the screen and input back. The last step is a script because a layout built by hand disappears when the server reboots, while a script stays.

Steps

1. Create a session named work.
2. Add windows to the work session so there are 3 or more in total, and name one of them logs.
3. Rename window 0 of the work session to edit.
4. Detach from the work session. The session must stay alive and no client may be attached.
5. Create a deploy session without attaching, with a window named build inside it.
6. Create /root/.tmux.conf and set these four things: prefix C-a, mouse on, window index starting at 1, and pane index starting at 1.
7. Create any file and, in the work session's logs window, follow it with tail -f. It must still be running when grading happens.
8. Create /root/tmux/session.sh <세션이름> (the argument is the session name). It creates a session with the name given as the argument without attaching, and the session must contain two windows, api and db. It must succeed even when run twice with the same name, and the number of windows must not grow.

Notes

• You can create a session without attaching with tmux new-session -d -s 이름 -n 첫윈도우이름 (session name, then the name of the first window).
• tmux has-session -t 이름 2>/dev/null returns 0 if the session exists. It is the key to idempotency.
• The target notation is 세션:윈도우.페인 (session:window.pane). Write it like work:logs.
• To check step 6, the grader starts a temporary server on a separate socket and has it actually read that configuration file. Even if the file contains the settings, it fails if there is a syntax error.
• Common mistake 1: if you hardcode the session name in step 8, taking an argument is pointless.
• Common mistake 2: if you leave out -d in step 8, the script tries to attach and hangs in automation.

Create your first session

Create a session named work.

Create it with tmux new -s name. Creating a session also starts the server.

Add windows and name them

Add windows to the work session so there are 3 or more in total, and name one of them logs.

prefix + c creates a new window and prefix + , renames it. From the CLI, use new-window -n name.

Rename window 0

Rename window 0 of the work session to edit.

You can specify the target of the rename-window command with -t. The target notation has the form session:window.

Detach the session

Detach from the work session. The session must stay alive and no client may be attached.

Detach with prefix + d. The session must not disappear; it must remain inside the server.

Create a session without attaching

Create a deploy session without attaching, with a window named build inside it.

The -d option creates the session without attaching. Specify the name of the first window with -n.

Create the configuration file

Create /root/.tmux.conf and set these four things: prefix C-a, mouse on, window index starting at 1, and pane index starting at 1.

Changing the prefix needs both unbind and set -g. pane-base-index is a window option, so specify it with setw.

Keep a long-running process in a session

Create any file and, in the work session's logs window, follow it with tail -f. It must still be running when grading happens.

Create a file and follow it with tail -f. It must keep running in the logs window.

Session bootstrap script

Create /root/tmux/session.sh <세션이름> (the argument is the session name). It creates a session with the name given as the argument without attaching, and the session must contain two windows, api and db. It must succeed even when run twice with the same name, and the number of windows must not grow.

Take the session name as $1, and if it already exists leave it alone and succeed. You can check with has-session.