Linux connect to pts

Difference between /dev/tty and /dev/pts (tty vs pts) in Linux

Table of Contents

What is the difference between /dev/pts and /dev/tty. What is /dev/tty and /dev/pts. Why do I get /dev/pts instead of /dev/tty on my Linux terminal. TTY vs PTS. /dev/tty vs /dev/pts. What is the difference between /dev/pts and /dev/pty.

tty vs pts

In the article I will give you a brief overview on the difference between /dev/tty and /dev/pts i.e. tty vs pts in Linux.

• terminal = tty = text input/output environment
• Teletypewriter originally and now also means any terminal on Linux/Unix systems. It also means any serial port on Unix/Linux systems
• A tty is a regular terminal device (the console on your server, for example).
• tty consoles are managed by systemd in Red Hat Enterprise Linux 7 OS.
• tty consoles are created on-the-fly upon access.
• The allowed number of consoles can be configured in /etc/systemd/logind.conf file.
• Set NAutoVTs= value in this file to desired number to have systemd capable of generating those many tty consoles.

To get the list of open terminals

• This continues upto tty6 i.e. default number of allowed tty consoles are 6
• One can switch from tty1 to tty6 using Ctrl+Alt+F6 on the console
• Below screenshot is from my HP iLO console where you can view the terminal id

• Stands for pseudo terminal slave.
• A pts is the slave part of a pty.
• A pty (pseudo terminal device) is a terminal device which is emulated by an other program (example: xterm, screen, or ssh are such programs).
• /dev/pts contains entries corresponding to devices. /dev/pts is a special directory that is created dynamically by the Linux kernel. The contents of the directory vary with time and reflect the state of the running system.
• The entries in /dev/pts correspond to pseudo-terminals (or pseudo-TTYs, or PTYs).
• In laymen terms the primary difference between TTY and PTS is the type of connection to the computer. TTY ports are direct connections to the computer such as a keyboard/mouse or a serial connection to the device. PTS connections are SSH connections or telnet connections. All of these connections can connect to a shell which will allow you to issue commands to the computer.

Lastly I hope the steps from the article to understand the difference between tty and pts i.e. tty vs pts on Linux was helpful. So, let me know your suggestions and feedback using the comment section.

Related Posts

Didn’t find what you were looking for? Perform a quick search across GoLinuxCloud

If my articles on GoLinuxCloud has helped you, kindly consider buying me a coffee as a token of appreciation.

For any other feedbacks or questions you can either use the comments section or contact me form.

Thank You for your support!!

Источник

What is stored in /dev/pts files and can we open them?

According to my knowledge, /dev/pts files are created for ssh or telnet sessions.

3 Answers 3

Nothing is stored in /dev/pts . This filesystem lives purely in memory.

Entries in /dev/pts are pseudo-terminals (pty for short). Unix kernels have a generic notion of terminals. A terminal provides a way for applications to display output and to receive input through a terminal device. A process may have a controlling terminal — for a text mode application, this is how it interacts with the user.

Terminals can be either hardware terminals (“tty”, short for “teletype”) or pseudo-terminals (“pty”). Hardware terminals are connected over some interface such as a serial port ( ttyS0 , …) or USB ( ttyUSB0 , …) or over a PC screen and keyboard ( tty1 , …). Pseudo-terminals are provided by a terminal emulator, which is an application. Some types of pseudo-terminals are:

• GUI applications such as xterm, gnome-terminal, konsole, … transform keyboard and mouse events into text input and display output graphically in some font.
• Multiplexer applications such as screen and tmux relay input and output from and to another terminal, to decouple text mode applications from the actual terminal.
• Remote shell applications such as sshd, telnetd, rlogind, … relay input and output between a remote terminal on the client and a pty on the server.

If a program opens a terminal for writing, the output from that program appears on the terminal. It is common to have several programs outputting to a terminal at the same time, though this can be confusing at times as there is no way to tell which part of the output came from which program. Background processes that try to write to their controlling terminal may be automatically suspended by a SIGTTOU signal.

If a program opens a terminal for reading, the input from the user is passed to that program. If multiple programs are reading from the same terminal, each character is routed independently to one of the programs; this is not recommended. Normally there is only a single program actively reading from the terminal at a given time; programs that try to read from their controlling terminal while they are not in the foreground are automatically suspended by a SIGTTIN signal.

To experiment, run tty in a terminal to see what the terminal device is. Let’s say it’s /dev/pts/42 . In a shell in another terminal, run echo hello >/dev/pts/42 : the string hello will be displayed on the other terminal. Now run cat /dev/pts/42 and type in the other terminal. To kill that cat command (which will make the other terminal hard to use), press Ctrl + C .

Writing to another terminal is occasionally useful to display a notification; for example the write command does that. Reading from another terminal is not normally done.

Источник

Linux: Connect to another a terminal session

I can use screen or tmux to connect to other terminal sessions, or to share them. But this work only when we first know we will use them.
As root can access everything, is there a way to do the same thing without running screen ? Some pipes through tee or so.

For example to remotely take over a console or ssh session someone left open. Allowing to see what’s on and close things correctly.

4 Answers 4

I only know a systemtap recipe. Hawfully basic, but maybe someone skilled could improve it.

Else you can have a look at conspy . I know you use Debian, just apt-get it. It only has access to the console, not ssh.
ttysnoop is nice but, as you stated, needs to be installed first.

In the past I used TTYsnoop, which still seems to be included in Debian and Ubuntu.

Short answer: not with stock tools.

You could cobble something together that poked the kernel and trolled through file descriptors, but the effort you would have to put in would be far greater than the return you would get from it.

I had the problem of doing an upgrade of ubuntu over ssh and lost the connection right in the middle. I thought I was doomed. After some research, I found that I could resume an existing ssh session using a command line option of screen.

First, I ran the following.

This gave me a list of existing sessions. Each session was listed with a PID. So, I then ran the following command to get the abandoned session back.

I am so glad I found this and was able to continue the upgrade. I had a feeling that rebooting would have ruined everything and was out of the question.

Источник

What is responsible for connecting /dev/pts/10 with stdout/stdin/stderr?

When running a command on a tty in a terminal it returns /dev/pts/10 .

Besides that there are the files /dev/stdout /dev/stdin and /dev/stderr . Interacting with them directly shows results in the terminal.

Also any cli app, started from the shell, will have the file descriptors open for stdout / stderr / stdin . i.e. if you run a script that prints something, printing is an equivalent of writing to stdout .

So far stdout / stderr / stdin were the only interfaces the shell works with. That is also true for the apps.

Some OS component is eventually moving the data that is written to stdout to the terminal otherwise I wouldn’t see anything printed.

When and where does a connection between stdout/stdin/stderr and the terminal happen so that interacting with std* actually result with something on the terminal?

My rough assumption that I’d like to have challenged is:

/dev/stdout , /dev/stdin and /dev/stderr are created by the running shell, they don’t exist without a shell.

The shell sets up the communication channel with the actual device file representing the terminal ( /dev/pts/10 ) and exposes the terminal functionalities through /dev/stdout , /dev/stdin and /dev/stderr . This way the shell provides the apps with a simple file interface instead of having every app worrying how to work the device file for simple printing.

Update

Even though /dev/pts/10 is a pseudoterminal, I’ll value more the answers which manage to give the answer without introducing the pseudoterminal concept. I’m coming from a perspective that it will only distract from the answer to the question:

When and where does a connection between stdout/stdin/stderr and the terminal happen so that interacting with /dev/std* actually result with something on the terminal?

3 Answers 3

/dev/pts/10 is the slave end of a pseudoterminal device pair. At the other end is the program that opened the master clone device /dev/ptmx and received /dev/pts/10 as pair (every time you open /dev/ptmx , you obtain a different slave). The connection between /dev/ptmx and /dev/pts/10 is basically a bidirectional pipe with a twist.

When you open a terminal emulator application:

• it opens /dev/ptmx and obtains the name of the other end. It configures the other end and opens it up,
• it forks,
• the new process opens the other end of the pseudoterminal device and connects its stdin, stdout and stderr to it,
• the new process executes the shell.

The shell does nothing to setup these three file descriptors, it inherits them from its parent process. The same way its children will inherit the file descriptors from the shell.

Remark: On a Linux system /dev/stdin , /dev/stdout and /dev/stderr are real files, which by a series of symbolic links point to /proc/

/2 , which in turn point to the real input/output device: in your case /dev/pts/10 .

The existence of these three standard streams is guaranteed by the C library.

Edit: to address your updated question, let’s clarify some points of the answer:

• everything written to /proc/pts/* is read by the terminal that created it and displayed, everything read from /proc/pts/* comes from an input device connected to the terminal,
• on Linux /dev/stdout is often a symbolic link to /proc/self/fd/1 , while /dev/stdin a symbolic link to /proc/self/fd/0 . The virtual /proc filesystem takes care to show to every application /proc/self as a symbolic link to /proc/

is the applications process id.
the symbolic links in /proc/

/fd point to the files, pipes and other stuff opened by an application or inherited from their parent. Every application is guaranteed to have three file descriptors open: 0 to read input, 1 to write output, 2 to write errors. In your case it is /dev/pts/10 .

If you don’t redirect output to another file, every command run by the shell write to the terminal. The exception to this rule is if your command’s process group is different from the foreground process group of the terminal, than the write will fail and SIGTTOU will be sent to the command. This behaviour can be controlled with stty tostop and stty -tostop :

/fd are actually a link to /dev/pts/21 . And that /dev/pts/21 can be directly read/written to, I’d accept your answer and grant you the bounty.

A POSIX-compliant program can expect to inherit file descriptors #0, #1 and #2 (also known by programming constants stdin , stdout and stderr , respectively) from its parent process, in an already-opened, ready-to-use state.

In the simplest case, of a command-line program in a session logged in on the text console, with no redirections applied, this chain of inheritance goes all the way back to the getty process that initialized the TTY device for the login session.

When logging in using a GUI, the display manager process ( gdm/kdm/sddm/lightdm/xdm/ dm ) will usually set the standard input and output to /dev/null and standard error to $HOME/.xsession-errors or something similar for the first process of the session, and these file descriptors are likewise inherited by all the GUI programs started in the session, either as parts of the desktop environment, or started using desktop menus or icons.

For e.g. SSH sessions, the sshd process that forked to initialize the session would have allocated a pseudo-TTY device pair, pointed the stdin/out/err file descriptors to one half of it, and then exec() ed the user’s shell. The other side of that fork will keep hold of the other half of the pseudo-TTY device pair, and will be handling the en/decryption of the outgoing/incoming traffic between the network and the pseudo-TTY device, until the session ends.

When a terminal emulator is started within a GUI session, it behaves essentially the same as the sshd process when initializing a new session: it allocates a pseudo-TTY, fork() s itself, and one copy sets up the session, including pointing file descriptors #0, #1 and #2 to the pseudo-TTY and finally exec() s the user’s shell, and the other side of the fork will remain handling the task of actually maintaining the visual representation of the terminal window.

So, in a nutshell, the (pseudo?)TTY device was connected to stdin/stdout/stderr by the thing that initialized your terminal session, and all the processes that may be between that and your application simply passed them down in a chain of inheritance, by doing nothing at all to those file descriptors, just letting them pass to their child process as-is.

When redirection operators are used in shell command line, as the shell fork() s a temporary copy of itself in preparation to actually exec() ing the command, just after the fork() the temporary copy will close the respective file descriptor, open the thing specified by the redirection operator in its place, and then exec() the command so that it will inherit the modified stdin/out/err file descriptor(s).

In some Unix-style systems /dev/std* devices might be handled by the shell. But Linux makes them a bit more «real».

In Linux, /dev/stdin , /dev/stdout and /dev/stderr are just plain old symbolic links pointing to the /proc filesystem:

These links are created as the udev RAM-based /dev filesystem is initialized at system boot-up. They are just regular plain symbolic links, nothing magical there.

But /proc is an entirely virtual filesystem that reflects the state of the processes in the system in real-time, and so it has several «magical» properties:

/proc/self is a symbolic link that points to the /proc/

directory of the process that looks at it:

/proc/

/fd is a directory that contains symbolic links with their names corresponding to file descriptors opened by the process with

, and pointing to whatever that file descriptor is associated with.

So, when a process on /dev/pts/10 tries to access /dev/stdin , the symbolic link points it to /proc/self/fd/0 instead. and when /proc/self/fd/0 is accessed, the /proc filesystem driver looks at the kernel’s process table, uses it to find the file descriptor table of the process that is accessing it, and presents /proc/self/fd/0 as a symbolic link to /dev/pts/10 . precisely because that process currently has /dev/pts/10 associated with its file descriptor #0.

On Solaris 11, the /dev/std* devices are symbolic links to /dev/fd/ directory, which is similarly «magical»:

Here, the Solaris /dev filesystem driver implements the magic using device nodes in the /dev/fd directory instead of redirecting to /proc filesystem, as Linux does for historical reasons.

Источник