Overview of the Differences between Linux TTY/PTS

When we type a letter on the keyboard, how is it sent to the corresponding process? What are the functions and differences of the outputs like tty1 and pts/0 that we see through commands such as ps and who?

TTY History

Before multitasking computers

Before computers came along, people were using a device called a teletype to send messages to each other. It looked like this:

+----------+ Physical Line +----------+
| teletype |<--------------------->| teletype |
+----------+ +----------+

The two teletypes are connected by a wire, and there may be devices similar to modems at both ends of the wire (they are ignored here). When you type on the teletype at one end, the corresponding data will be sent to the teletype at the other end. I don’t know what the specific functions are. (The image in my head is typing on one end and printing out on the other end)

These are antiques and I have never come across them, so I can only make simple guesses.

After the emergence of computers that support multitasking

When computers supported multitasking, people thought of connecting these teletypes to computers and using them as computer terminals to operate the computers.

There are two main reasons to use teletype (personal opinion):

• In reality, there are already a large number of teletypes from different manufacturers, and we can make full use of existing resources
• Teletype's related network is already quite mature and easy to connect

So the connection develops like this:

                                   +----------+ 
+----------+ +-------+ Physical Line +-------+ +------+ | |
| Terminal |<->| Modem |<--------------------->| Modem |<->| UART |<->| Computer |
+----------+ +-------+ +-------+ +------+ | |
                                   +----------+

• The Terminal on the left is a variety of teletypes
• Modems, which we often call "cats", are used on both sides of the physical line. This is because the Internet has gradually become more developed and everyone can share the connection. (Rough guess, may be wrong)
• UART can be understood as a device that converts teletype signals into signals that can be recognized by computers.

Kernel TTY subsystem

In order to support these teletypes, computers designed a subsystem called TTY, the internal structure of which is as follows:

  +-----------------------------------------------+
  | Kernel |
  | +--------+ |
  | +--------+ +------------+ | | | +----------------+
  | | UART | | Line | | TTY |<---------->| User process A |
<------>| |<->| |<->| | | +----------------+
  | | driver | | discipline | | driver |<---------->| User process B |
  | +--------+ +------------+ | | | +----------------+
  | +--------+ |
  | |
  +-----------------------------------------------+

• UART driver connects to external UART devices
• Line discipline is mainly responsible for processing input and output. It can be understood that it is part of the TTY driver.
• TTY driver is used to handle various terminal devices
• User space processes interact with the terminal through the TTY driver

For the sake of simplicity, the UART driver and Line discipline will not be listed separately in the following introduction. They can be considered as part of the TTY driver.

TTY Devices

For each terminal, the TTY driver will create a TTY device corresponding to it. If multiple terminals are connected, it will look like this:

           +----------------+
           |TTY Driver |
           | |
           | +-------+ | +----------------+
 +------------+ | | |<---------->| User process A |
 | Terminal A |<--------->| ttyS0 | | +----------------+
 +------------+ | | |<---------->| User process B |
           | +-------+ | +----------------+
           | |
           | +-------+ | +----------------+
 +------------+ | | |<---------->| User process C |
 | Terminal B |<--------->| ttyS1 | | +----------------+
 +------------+ | | |<---------->| User process D |
           | +-------+ | +----------------+
           | |
           +----------------+

When the driver receives a terminal connection, it creates a corresponding tty device based on the terminal model and parameters (the device name in the figure above is ttyS0 because most terminals are connected via serial connections). Since each terminal may be different and have its own special commands and usage habits, the configuration of each tty device may be different. For example, when you press the delete key, some may delete the preceding character, while others may delete the following character. If it is not configured correctly, some keys will not behave as you want. This is why when we use an analog terminal, if the default configuration does not match our habits, we need to make some personalized configurations.

Later, with the continuous development of computers, teletype devices gradually disappeared. We no longer needed special terminal devices. Each machine had its own keyboard and monitor, and each machine could be the terminal of other machines. Remote operations were achieved through ssh, but the kernel TTY driver architecture did not change. If we wanted to perform I/O interaction with processes in the system, we still needed to use TTY devices. As a result, various terminal emulation software appeared, and they also simulated several common terminals, such as VT100, VT220, XTerm, etc.

• You can use the command toe -a to list all terminal types supported by the system.
• You can use the infocmp command to compare the differences between two terminals. For example, infocmp vt100 vt220 will output the differences between vt100 and vt220.

How programs interact with TTYs

Before discussing how TTY devices are created and configured, let's first look at how TTY is used by a process:

#First use the tty command to see which tty the current bash is associated with
dev@debian:~$ tty
/dev/pts/1

#See which processes have opened ttys dev@debian:~$ lsof /dev/pts/1
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
bash 907 dev 0u CHR 136,1 0t0 4 /dev/pts/1
bash 907 dev 1u CHR 136,1 0t0 4 /dev/pts/1
bash 907 dev 2u CHR 136,1 0t0 4 /dev/pts/1
bash 907 dev 255u CHR 136,1 0t0 4 /dev/pts/1
lsof 1118 dev 0u CHR 136,1 0t0 4 /dev/pts/1
lsof 1118 dev 1u CHR 136,1 0t0 4 /dev/pts/1
lsof 1118 dev 2u CHR 136,1 0t0 4 /dev/pts/1

#Writing data directly into tty has the same effect as writing to standard output dev@dev:~$ echo aaa > /dev/pts/2
aaa

PTS is also a tty device. Their relationship will be introduced later.

From the above lsof, we can see that the stdin(0u), stdout(1u), and stderr(2u) of the currently running bash and lsof processes are all bound to this TTY.

The following is a diagram of the interaction between tty, processes, and I/O devices:

  Input +--------------------------+ R/W +------+
----------->| |<---------->| bash |
      | pts/1 | +-----+
<-----------| |<---------->| lsof |
  Output | Foreground process group | R/W +------+
      +--------------------------+                

• You can think of tty as a pipe. What is written at one end can be read from the other end, and vice versa.
• Here, input and output can be simply understood as keyboard and display. Later we will introduce what input/output is connected to in various situations.
• There is a very important attribute in tty, called Foreground process group, which records which is the current front-end process group. The concept of process group will be introduced in the next article. Here, we can simply assume that there is only one process in the process group.
• When pts/1 receives the input, it checks which is the current front-end process group, and then puts the input into the input buffer of the leader of the process group, so that the corresponding leader process can get the user's input through the read function.
• When the process in the front-end process group writes data to the tty device, the tty will output the data to the output device
• When executing different commands in the shell, the front-end process group is constantly changing, and the shell is responsible for updating this change to the tty device.

As can be seen from the above, it is very simple to deal with processes and tty. Just make sure that the background process does not read or write tty. That is, when writing background programs, stdin/stdout/stderr should be redirected to other places (of course, the deamon program also needs to do a lot of other processing).

First, let me ask two questions (with answers later):

• What happens when a process in a non-frontend process group (background process) writes data to a tty device? Will it be output to outpu?
• What happens when a process in a non-foreground process group (background process) reads data from a tty device? Will the process be blocked?

How TTY was created

The following describes how tty devices are created in several common situations, as well as what input and output devices are.

Keyboard display direct connection (terminal)

Look at the picture before talking:

          +-----------------------------------------+
          | Kernel |
          | +--------+ | +----------------+ 
 +----------+ | +-------------------+ | tty1 |<---------->| User processes |
 | Keyboard |--------->| | +--------+ | +----------------+
 +----------+ | | Terminal Emulator |<->| tty2 |<---------->| User processes |
 | Monitor |<---------| | +--------+ | +----------------+
 +----------+ | +-------------------+ | tty3 |<---------->| User processes |
          | +--------+ | +----------------+
          | |
          +-----------------------------------------+

The keyboard and monitor are connected to the terminal emulator in the kernel. The emulator decides how many ttys to create. For example, when you enter ctrl+alt+F1 on the keyboard, the emulator first captures the input and then activates tty1. The keyboard input will be forwarded to tty1, and the output of tty1 will be forwarded to the monitor. Similarly, if you enter ctrl+alt+F2, you will switch to tty2.

When the simulator activates the tty, if it finds that there is no process associated with it, it means that this is the first time the tty is opened, so it will start the configured process and bind it to the tty. Generally, this process is the process responsible for login.

When switching to tty2, where will the output in tty1 be output to? The output of tty1 will still be output to the emulator, and there will be a cache for each tty in the emulator. However, due to the limited cache space of the emulator, the next time you switch back to tty1, you can only see the latest output, and the previous output will no longer be there.

I'm not sure which module in the kernel the terminal emulator corresponds to, but it definitely exists.

SSH Remote Access

 +----------+ +------------+
 | Keyboard |------>| |
 +----------+ | Terminal |
 | Monitor |<------| |
 +----------+ +------------+
             |
             | ssh protocol
             |
             ↓
          +------------+
          | |
          | ssh server |--------------------------+
          | | fork |
          +------------+ |
            | ↑ |
            | | |
         write | | read |
            | | |
         +-----|---|-------------------+ |
         | | | | ↓
         | ↓ | +-------+ | +-------+
         | +--------+ | pts/0 |<---------->| shell |
         | | | +-------+ | +-------+
         | | ptmx |<->| pts/1 |<---------->| shell |
         | | | +-------+ | +-------+
         | +--------+ | pts/2 |<---------->| shell |
         | +-------+ | +-------+
         | Kernel |
         +-----------------------------+

The Terminal here may be a program anywhere, such as putty on Windows, so we will not discuss how the client's Terminal program interacts with the keyboard and display. Since Terminal needs to interact with the ssh server, the ssh client function must be implemented.

Here we will explain the establishment of connection and sending and receiving data in two lines. For the sake of simplicity, sshd is used instead of ssh server program:

Establishing a connection

1.Terminal requests to establish a connection with sshd

2. If the verification is successful, sshd will create a new session

3. Call API (posix_openpt()) to request ptmx to create a pts. After successful creation, sshd will get the fd associated with ptmx and associate the fd with the session.

#pty (pseudo terminal device) consists of two parts, ptmx is the master end, pts is the slave end,
#The process can request ptmx to create a pts by calling the API, and then it will get the read-write fd connected to ptmx and a newly created pts.
#ptmx will maintain the correspondence between the fd and pts internally, and then the read and write operations to this fd will be forwarded by ptmx to the corresponding pts.

#Here you can see that sshd has opened /dev/ptmx
dev@debian:~$ sudo lsof /dev/ptmx
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
sshd 1191 dev 8u CHR 5,2 0t0 6531 /dev/ptmx
sshd 1191 dev 10u CHR 5,2 0t0 6531 /dev/ptmx
sshd 1191 dev 11u CHR 5,2 0t0 6531 /dev/ptmx

4. At the same time, sshd creates a shell process and binds the newly created pts to the shell

Send and receive messages

1.Terminal receives keyboard input and sends the data to sshd via ssh protocol

2. After sshd receives the data from the client, it finds the fd associated with ptmx corresponding to the client according to the session it manages

3. Write the data sent by the client to the found fd

4. After ptmx receives the data, it finds the corresponding pts according to fd (the corresponding relationship is automatically maintained by ptmx) and forwards the data packet to the corresponding pts

5. After receiving the data packet, pts checks the current front-end process group bound to it and sends the data packet to the leader of the process group

6. Since there is only shell on pts, the shell's read function receives the data packet

7. The shell processes the received data packets and then outputs the processing results (or there may be no output)

8. Shell writes the result to pts through the write function

9.pts forwards the results to ptmx

10.ptmx finds the corresponding fd according to pts and writes the result to the fd

11. After sshd receives the result of the fd, it finds the corresponding session and sends the result to the corresponding client

Keyboard and display direct connection (graphical interface)

 +----------+ +------------+
 | Keyboard |------>| |
 +----------+ | Terminal |--------------------------+
 | Monitor |<------| | fork |
 +----------+ +------------+ |
            | ↑ |
            | | |
         write | | read |
            | | |
         +-----|---|-------------------+ |
         | | | | ↓
         | ↓ | +-------+ | +-------+
         | +--------+ | pts/0 |<---------->| shell |
         | | | +-------+ | +-------+
         | | ptmx |<->| pts/1 |<---------->| shell |
         | | | +-------+ | +-------+
         | +--------+ | pts/2 |<---------->| shell |
         | +-------+ | +-------+
         | Kernel |
         +-----------------------------+

For the sake of simplicity, this article does not discuss how the Terminal program in the graphical interface under Linux interacts with the keyboard and display.

The difference between here and the above is that the Terminal here does not need to implement the ssh client, but it needs to do the work that the ssh server needs to do (except for ssh communication related work of course).

SSH + Screen/Tmux

Students who often use Linux should be familiar with screen and tmux. The processes started by them will continue to execute even if the network is disconnected. The next time you connect, you can still see all the output of the process and continue to work.

Here we take tmux as an example to introduce its principle:

 +----------+ +------------+
 | Keyboard |------>| |
 +----------+ | Terminal |
 | Monitor |<------| |
 +----------+ +------------+
             |
             | ssh protocol
             |
             ↓
          +------------+
          | |
          | ssh server |--------------------------+
          | | fork |
          +------------+ |
            | ↑ |
            | | |
         write | | read |
            | | |
         +-----|---|-------------------+ |
         | ↓ | | ↓
         | +--------+ +-------+ | +-------+ fork +-------------+
         | | ptmx |<->| pts/0 |<---------->| shell |-------->| tmux client |
         | +--------+ +-------+ | +-------+ +-------------+
         | | | | ↑
         | +--------+ +-------+ | +-------+ |
         | | ptmx |<->| pts/2 |<---------->| shell | |
         | +--------+ +-------+ | +-------+ |
         | ↑ | Kernel | ↑ |
         +-----|---|-------------------+ | |
            | | | |
            |w/r| +---------------------------+ |
            | | | fork |
            | ↓ | |
          +-------------+ |
          | | |
          | tmux server |<--------------------------------------------+
          | |
          +-------------+

There is only one ptmx in the system, but two are drawn in the figure above to show that both the tmux server and sshd use ptmx, but they do not interfere with each other.

This situation is a little more complicated, but the principle is the same. The first half is the same as the ordinary ssh method, except that the front-end process associated with pts/0 is not a shell, but a tmux client. Therefore, the data packets sent by the ssh client will be received by the tmux client, and then forwarded by the tmux client to the tmux server. The work done by the tmux server is similar to that of ssh. It also maintains a bunch of sessions, creates a pts for each session, and then forwards the data sent by the tmux client to the corresponding pts.

Since the tmux server only deals with the tmux client and has nothing to do with sshd, when the connection between the terminal and sshd is disconnected, although pts/0 will be closed and the shell and tmux client related to it will also be killed, it will not affect the tmux server. When you use the tmux client to connect to the tmux server next time, you will still see the last content.

Difference between TTY and PTS

It should be clear from the above process that for user-space programs, there is no difference between them, they are all the same; from the kernel's perspective, the other end of pts is connected to ptmx, and the other end of tty is connected to the kernel's terminal emulator, and both ptmx and the terminal emulator are only responsible for maintaining sessions and forwarding data packets; looking at the other end of ptmx and the kernel terminal emulator, the other end of ptmx is connected to user-space applications, such as sshd, tmux, etc., and the other end of the kernel terminal emulator is connected to specific hardware, such as keyboards and monitors.

Common TTY configurations

Let's first take a look at all the configurations of the current tty:

dev@dev:~$ stty -a
speed 38400 baud; rows 51; columns 204; line = 0;
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = M-^?; eol2 = M-^?; swtch = <undef>; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W; lnext = ^V; discard = ^O; min = 1; time = 0;
-parenb -parodd -cmspar cs8 -hupcl -cstopb cread -clocal -crtscts
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr icrnl ixon -ixoff -iuclc ixany imaxbel -iutf8
opost -olcuc -ocrnl onlcr -onocr -onlret -ofill -ofdel nl0 cr0 tab0 bs0 vt0 ff0
isig icanon iexten echo echoe echok -echonl -noflsh -xcase -tostop -echoprt echoctl echoke -flusho -extproc

stty can also be used to modify tty parameters. For usage, please refer to man stty

Any program with permissions can modify the TTY configuration through the API provided by Linux. The following are some common configuration items.

rows 51; columns 204;

This configuration is generally controlled by the terminal. When the terminal window size changes, the configuration needs to be modified through certain means. For example, there are parameters for modifying the window size in the ssh protocol. After sshd receives the client's request, it will modify this parameter of tty through the API, and then tty will notify the front-end program (such as shell or vim) through the signal SIGWINCH. After receiving the signal, the front-end program will read this parameter of tty and know how to adjust its output formatting.

intr = ^C

In addition to forwarding data between the terminal and the front-end process, tty also supports many control commands. For example, if CTRL+C is entered in the terminal, the tty will not forward the input string to the front-end process, but convert it into a signal SIGINT and send it to the front-end process. This is used to configure the input combination corresponding to the control command. For example, we can configure "intr = ^E" to replace CTRL+C with CTRL+E.

start = ^Q; stop = ^S;

These are two special control commands that many people probably encounter often. After accidentally entering CTRL+S on the keyboard, the terminal becomes unresponsive, meaning there is no output and no response to any input. This is because this command will tell TTY to pause and block all read and write operations, that is, no data will be forwarded, and it will continue only after pressing CTRL+Q. This function should be a historical legacy. In the past, there was no flow control function between the terminal and the server, so it was possible that the server sent data too fast, causing the terminal to be unable to process it. Therefore, such a command was needed to tell the server not to send any more data, and to notify the server to continue after the terminal had processed it.

A common scenario for this command is to use the tail -f command to monitor the contents of a log file. You can press CTRL+S at any time to stop the screen from refreshing, and then press CTRL+Q to continue refreshing after reading. Otherwise, you need to press CTRL+C to exit first, and then re-run the tail -f command after reading.

echo

When we input characters in the terminal, the reason why we can see the characters we input in time is that after TTY receives the characters sent by the terminal, it will first return a copy of the characters by the original path, and then hand them over to the front-end process for processing, so that the terminal can display the input characters in time. echo is the configuration item used to control this function. If it is -echo, it means to disable the echo function.

-tostop

If you add & at the end when running a program in the shell, such as ./myapp &, the myapp process will run in the background, but what if the process continues to write data to the tty? This parameter is used to control whether the output is forwarded to the terminal, that is, whether the result will be displayed in the terminal. Here, "-tostop" means that the output will be sent to the terminal. If it is configured as "tostop", it will not be output to the terminal, and tty will send a signal SIGTTOU to myapp. The default behavior of this signal is to suspend the execution of myapp.

TTY related signals

In addition to the SIGINT, SIGTTOU, and SIGWINCHU mentioned in the configuration above, there are several other TTY-related signals.

SIGTTIN

When the background process reads the tty, the tty will send this signal to the corresponding process group. The default behavior is to suspend the execution of the process in the process group. How to continue the suspended process? Please refer to SIGCONT in the next article.

SIGHUP

When the other end of the tty hangs up, for example, the ssh session is disconnected, sshd closes the fd associated with ptmx, and the kernel sends a SIGHUP signal to all processes related to the tty. The default behavior of the process after receiving the signal is to exit the process.

SIGTSTP

When CTRL+Z is entered in the terminal, the tty will send SIGTSTP to the front-end process group after receiving it. Its default behavior is to put the front-end process group to the back-end and suspend the execution of all processes in the process group.

All tty-related signals can be captured, and their default behavior can be modified

Conclusion

This article introduces the common functions and features of tty. The next article will introduce in detail the process session ID, process group, job, background program, etc. that are closely related to tty. Stay tuned.

refer to

The TTY demystified

The above is the full content of this article. I hope it will be helpful for everyone’s study. I also hope that everyone will support 123WORDPRESS.COM.