2

I have one computer running Debian Wheezy(screen version 4.01.00devel) and another one Debian Squeeze(screen version 4.00.03jw4) and under both of them screen automatically starts another process named screen. For example:

init(1)-+-acpid(1926)
        |-sshd(2139)---sshd(2375)---bash(2448)---screen(6649)---screen(6650)-+-bash(6651)---pstree(6751)

According to ps PID 6649 command is screen and PID 6650 command is SCREEN:

root@vserver:~# ps -f -p 6650
UID        PID  PPID  C STIME TTY          TIME CMD
root      6650  6649  0 11:26 ?        00:00:00 SCREEN
root@vserver:~# 

Why does screen behave like this?

2

The outer screen (PID 6649) connects to the terminal you started from, and is terminated when you detach (Ctrl+a,d).

The inner screen (PID 6650) is not connected to that terminal, but rather controls its own pseudo-terminal (pty) device, to which the bash started from it is connected.

What happens is that when you enter something on the outer terminal, the outer screen gets it, sends it over a socket to the inner screen, and that in turn forwards the input to the pty it controls, so it ultimately reaches bash (or any other program started from bash, and controlled through the same pty). Output from bash (or any program started from it) will be sent to the inner screen's pty, which causes the inner screen sent it through the socket to the outer screen, which ultimately sends it to the terminal you started screen from (which in your case is again a pty created by ssh). Note that the socket is controlled by the inner screen, which allows detaching and re-attaching (see below).

If you detach the screen instance, what happens is that the inner screen, and with it the pty it controls, continues to exist. This is why the processes connecting to it, will survive, even if they try to do I/O. However the outer screen will terminate, thus breaking the connection with the outer terminal. You can now for example terminate the ssh session, and thus destroy the corresponding pty, and it will not affect the inner screen nor the programs started by it, since they communicate through their own pty device.

If you now log in again (creating another pty), and then call screen -r, the newly created screen instance will be connected to the terminal you started it from (which is completely separate from the one the first instance was started from, since you destroyed that), and then use the socket provided by the inner screen instance to re-connect with the inner screen, which will then send the current state of its own pty to the "outer" screen to display again; afterwards, the same I/O transmission line happens as with the previous outer screen instance.

If you now do a pstree, you'll find two lines with screen: One starting at sshd and ending at the new "outer" screen instance, and one starting with the "inner" screen instance which now no longer has a parent since that terminated when you detached the screen.

So in short:

  • The "outer" screen (PID 6649) connects with the terminal you're interacting with (in your case, the pty set up by ssh) and only lives as long as you're attached to the screen instance.
  • The "inner" screen (PID 6650) provides a separate pty for the programs you start under screen, and also provides the socket used to communicate the terminal state between the outer and the inner screen instance. It lives until you terminate screen (as opposed to detaching).
  • The separation is necessary to allow the controlled programs to survive the death of the outer pty (by being connected to a different pty which along with its controlling process — the inner screen — survives detaching from the outer terminal), as well as to re-attach (by having the surviving inner screen provide a socket to which new instances of screen can connect).
0

I guess the reason for the second process (the one with PID 6650 in your sample) is to close tty connection (stdin, stdout and stderr), so you could logout. logg back in later an retake onwship of screen.

As you can see, PID 6650 is not connected to a tty (TTY column says '?').

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.