19

Is it possible to change the parent process of a process? If yes, how?

For example,

  • how does screen manage to attach a screen session and the processes running inside it to different shell processes? Is there change of parent process?

  • I seem to heard of other ways of change of shell process in which a program is running, but I don't remember. Is there also change of parent process of the program?

  • I thought disown on a process changes the parent process of the process, simply because the name disown implies that. But I found it is not true.

  • Emacs client can attach to emacs server on a different terminal tab. Is there change of parent process?

Lesmana
  • 27,439
Tim
  • 101,790
  • 1
    disown just removes a given child from a shell's internal list of child processes. The child's PPID remains that of the shell. The shell has forgotten that it ever started that child, but the kernel remembers. – Warren Young Apr 02 '15 at 22:55
  • Does the process remember its parent? – Tim Apr 02 '15 at 23:21
  • If it wants to know, it calls getppid(2), a system call, and system calls are handled by the kernel. A program could be confused by issuing that call, saving the value, and then using that value after its parentage has changed. There is a chance of a race condition here. – Warren Young Apr 02 '15 at 23:52
  • Sounds like an interesting new kernel feature. – ChuckCottrill Jul 08 '17 at 00:57

1 Answers1

17

The parent process id (ppid) of a process cannot be changed outside of the kernel; there is no setppid system call. The kernel will only change the ppid to (pid) 1 after the processes parent has terminated - if the process did not respond to a signal that the parent was terminated. For this to happen, the process needs to have ignored various signals (SIGHUP, SIGTERM, etc.) beforehand.

screen(1) has a very elegant means of handling detaching and reattaching. When you first start screen, you are actually starting a user interface (ui), which by default will create a daemon (the session manager). This daemon has no terminal associated with it, a new process group (setpgrp(2)), a new session id (setsid(2)). The daemon, running as SCREEN, will then create subprocesses connected to pseudo-terminals (pty), then multiplexes the data from the ptys and the ui (screen). The subprocesses think they are talking with a real terminal.

If the ui screen terminates, the daemon SCREEN will still be running, buffering data, handling signals, waiting for a new ui, etc. because it is a different process group and in its own session. When you reattach with a new ui screen, then the daemon will continue to multiplex as it was doing before. The daemon will run continue running until all subprocesses terminate, is killed, a fatal bug is encountered or the host reboots.

Arcege
  • 22,536
  • Thanks. I added "Emacs client can attach to emacs server on a different terminal tab. Is there change of parent process?" – Tim Apr 02 '15 at 00:51
  • 1
    Every process has only one parent, until either the parent dies or it dies. If it dies, the point is moot. If the parent dies, then the PPID becomes 1, the init process. This is the only time the parent process would change - when the parent process terminates. Connecting via interprocess communication (pipes, sockets, etc.) has no affect on the PPID. – Arcege Apr 02 '15 at 01:37
  • How does Emacs attach a client to a server in different terminal tabs? – Tim Apr 02 '15 at 02:02
  • The server would listen on a socket (usually a UNIX domain socket file) waiting for connections. The client(s) would open a connection on that socket. Tabs are irrelevant to the communication between the client and the server, it could different tabs, different teminal emulates (xterm vs rxvt vs terminal), or could be xemacs. Each client knows where to connect, so it could be from anywhere. – Arcege Apr 02 '15 at 02:37
  • 1
    The parent process ID does not always become 1. This received wisdom absolutism has been wrong for over 3 years, now. – JdeBP Apr 02 '15 at 15:47
  • Thanks, Arcege! (1) When detach a screen session (reattachable later), what happen to the subprocess(es) running in the screen session and the screen session process? (2) when reattach a detached screen session, are the reattached screen session process and its subprocess(es) are the same as those before detaching? (3) Do you have some reference about what you said about screen, its manual doesn't say things like that, or I miss it? – Tim Apr 06 '15 at 18:22
  • Nothing happens to the subprocesses, they continue on as nothing has changed for them. If you are reattaching, then yes, the same server process and subprocesses will be connected to. You can tell screen to create a new session with new subprocesses, but then you wouldn't be reconnecting. Most of the reference is the source code itself. There is an info doc (info screen) with a bit more information, but not to the depth in this discussion. – Arcege Apr 08 '15 at 15:25
  • Thanks. Arcege. (1) Do screen daemon and ui communicate by interprocess communication (such as socket)? Does screen daemon runs a server, and a screen ui runs a client? (2) For emacs, does an emacs server run as a daemon, and an emacs client run as a ui? (3) Do screen (daemon and ui) and emacs (server and client) work in the same way? – Tim Feb 29 '16 at 06:37
  • I can't speak well for emacs; haven't really used it in 25 years. As far as I remember, it connected to an already running emacs process, so it wasn't able to run in the background like screen. To answer your first question: Yes, there is a UNIX domain socket that is used to access the server SCREEN process. Some systems have it in /tmp/screen/ others may be in /var/run/screen; when you run screen -ls, you'll see the directory ("1 Socket in /path/to/directory"). – Arcege Mar 03 '16 at 00:13